STG環境でのテスト・検証作業中に遭遇した疑問や気づき

# はじめに
STG環境でのテスト設計・検証作業中に遭遇した疑問や気づきを記録します。
主にStub通信やJUnitのテスト観点、設定ファイルの記述ミスによる失敗などです。

# 疑問に感じたこと
### 1. Stub通信ではなぜプロキシ設定が不要？
開発環境では、外部と通信する際にプロキシ設定が必要だが、Stubに対しては不要と聞いた。
理由が腑に落ちていなかったため調査。

#### 結論：
Stubはローカルネットワーク内（イントラ）で起動されるため、通常のインターネット経由ではなく直接アクセス可能。そのため、プロキシ経由のルートを必要としない。

今後は、通信先のドメインがどこにあるか（イントラorインターネット）をまず確認する癖をつける。

#### 補足：
| 違い | 内容 |
|:-:|:-:|
| ネットワーク範囲  | イントラネットは特定の組織内でのプライベートネットワークであり、インターネットは世界中の公共ネットワークです。  |
| アクセス制限  | イントラネットは通常、組織内部のユーザーのみがアクセス可能で、インターネットは誰でもアクセスできます。  |
| セキュリティ  | イントラネットは内部のセキュリティ対策が施されており、インターネットは外部からの脅威にさらされています。  |

### 2. 契約番号（Long型）のマスキングで比較エラー？
外部製品のファイルを使用したSTGテストにて、別部署に契約番号（Long型）をマスキング依頼すると、
比較処理でエラーになる可能性があると気づいた

#### 課題：
マスキングがLong型で問題になるのか？
もしかしたら「比較エラー」につながるのか？

#### 結論：
マスキング後の値が、数値の範囲外（例えば文字列化されたり、桁数が異常）になっている可能性
Long型は 精度が高く厳密な比較が行われるため、わずかなフォーマット差でも equals() 判定でNGになる可能性

#### 対策：
マスキング処理後、Long型として扱えるか、もしくは文字列化どちらに変換されるか問い合わせすること

#### 補足：
| 型名        | サイズ       | 値の範囲                                                   | 特徴                                    |
| --------- | --------- | ------------------------------------------------------ | ------------------------------------- |
| `byte`    | 8ビット      | -128 ～ 127                                             | 小さな整数を扱うのに適しており、メモリ効率が良い。             |
| `short`   | 16ビット     | -32,768 ～ 32,767                                       | `byte`より大きな整数を扱えるが、`int`や`long`より小さい。 |
| `int`     | 32ビット     | -2,147,483,648 ～ 2,147,483,647                         | 一般的な整数型で、ほとんどの整数計算に使用される。             |
| `long`    | 64ビット     | -9,223,372,036,854,775,808 ～ 9,223,372,036,854,775,807 | 非常に大きな整数を扱え、高精度な計算・比較に適している。          |
| `float`   | 32ビット     | 約 ±3.40282347×10³⁸（7桁の精度）                              | 単精度浮動小数点数で、少数の計算に使用されるが精度は低め。         |
| `double`  | 64ビット     | 約 ±1.7976931348623157×10³⁰⁸（15桁の精度）                    | 倍精度浮動小数点数で、高精度な計算が可能。                 |
| `char`    | 16ビット     | 0 ～ 65,535（Unicode 文字）                                 | 単一の文字を表現する型で、Unicodeに対応。              |
| `boolean` | 実装依存（論理値） | `true` または `false`                                     | 真偽値を表し、条件分岐などで使用される。                  |

 # 学び：JUnitテストで「逆算的」な検証ができる
 `ScrambleUtils.scramble()` のような内部ロジックの確認において、意図的に間違った値を入れて、失敗させることで「正しい形式」を推定できるという気づきがあった。

```Java:Sample.java
@Test
void testスクランブル処理 () {
    String input = "12345"; // 想定外の値
    String result = ScrambleUtils.scramble(input);
    assertNotNull(result); // 期待される挙動と異なるが正しい値を知れる
}    
    
```

# 失敗したこと
#### Stub通信の設定ミス
`host` や `port` の記載ミス
設定ファイル内のURL表記（http/httpsなど）ミス
これによりStubへ接続できず、原因特定に時間がかかった。
| 項目           | 説明                                        | 注意点・補足                                       |
| ------------ | ----------------------------------------- | -------------------------------------------- |
| `host`       | 接続先サーバのホスト名またはIPアドレス                      | 開発・検証環境ごとに値が異なる。タイポや環境差異に注意。                 |
| `port`       | 通信先のポート番号（例: `80`, `443`, `8080` など）      | サーバがListenしている正しいポートを指定すること。                 |
| `URL`        | 接続先の完全なアドレス。`http://host:port/path` 形式    | `http/https` の指定や末尾のスラッシュ有無にも注意。             |
| `http/https` | 通信プロトコル。`http`は暗号化なし、`https`はSSL/TLS暗号化あり | 環境によって使い分ける。証明書エラーやリダイレクトにも注意。               |
| ダンプログ        | 起動時や通信時に出力される、内部設定や通信内容のログ                | `host`, `port`, `URL`の確認に活用可。起動時に一度出力させると便利。 |

# 改善できる行動パターン
#### Stub通信の失敗時、原因仮説の切り口が浅かった
:::note warn
反省点
「とりあえずリトライして様子を見る」だけで、考察が浅かった
本来なら「接続先に到達できているか」「Stub側で例外を返しているか」「証明書系の問題か」など、層ごとの仮説を立てるべきだった
:::

Stub通信でのトラブル時に備えて、以下のような切り分け表をあらかじめ持っておくと、切り分けがスムーズになる：
| 現象      | 切り口    | 確認すべきこと             |
| ------- | ------ | ------------------- |
| 接続不可    | ネットワーク | host/port, プロキシ, FW |
| 通信エラー   | HTTP層  | ステータスコード, タイムアウト    |
| レスポンス不正 | データ構造  | JSON形式, 型の不整合       |
| リトライ多発  | リカバリ処理 | 実装ロジック, リトライ回数      |

# おわりに
今回の失敗や疑問点、また学びから言えることは、
現場で起きる“なんとなくの違和感”を放置せず、記録や対策を実施し、
立ち止まって確認する習慣が、トラブルの予防や成長につながると実感しました。