ラジオの話題01：テストが通った。その安心、どこまで？

今日の話題：①mockで確かめられること → ②interfaceを作る理由 → ③時間を止めてテストする。

気になるところから、思いついたことを自由に。全部を話す必要も、順番を守る必要もありません。下の小ネタは、話のきっかけや言葉の確認に使ってください。

← ラジオの話題一覧 · 元の振り返り・詳しい解説

1. mockが成功を返したら、何に安心できる？

話を広げるメモ

• 決済が成功した場合と、タイムアウトした場合。好きな条件を作れる便利さ。
• テストが通っても、実際に送るJSONや認証ヘッダーが間違っていたら？
• unit / integrationの違いを、クラス数や層数で説明できる？

小ネタ：stubとmockは、厳密には役割が違う

• test double：テストで使う代用品の総称。
• stub：呼ばれたら、用意した応答を返す。「決済成功を返す」など。
• mock：期待した呼び出しが行われたかを検証する。「この金額で課金を依頼したか」など。
• fake：簡略化した動く実装。たとえばテスト用のインメモリ保存先。

同じライブラリの「mockオブジェクト」で、stubとして応答を設定することも、呼び出しを検証することもできます。道具の名前と、テストで果たす役割は分けて考えると整理しやすいです。用語の範囲には流儀の違いもあります。

話の芯：何を本物にして、どこからを代用品にしたか。

2. テストのためにinterface、どこまで作る？

話を広げるメモ

• 「差し替えられるなら便利」から考え始めると、何にでも作りたくなる？
• 外部の決済サービスと、金額を計算するだけの関数。差し替えたい理由は同じ？
• 型やファイルが増えて、処理を追う手間との釣り合い。

小ネタ：DIは、独自interfaceを作ることではない

DI（依存性の注入）は、必要なものを外から渡すこと。コンストラクタで通信クライアントを渡すほか、計算関数へ日時や値を引数で渡すだけで済む場合もあります。DIコンテナも必須ではありません。

入力だけで結果が決まる計算なら、入力を変えて直接テストできます。一方、通信の失敗や時刻を制御したいなら、差し替える境界が役に立ちます。interfaceには業務の境界を表すなど、テスト以外の採用理由もあります。

話の芯：何を制御したいから、差し替えられるようにするのか。

3. 深夜料金のテストを、昼にやるには？

話を広げるメモ

• 毎回22時まで待つテスト。時計を外から渡せたら？
• 21時59分と22時ちょうど。なぜその2点を見る？
• 同じ瞬間、東京とニューヨークの店舗は同じ料金になる？

小ネタ：時計・時点・地域は別のもの

• Clock：現在時刻を取得する仕組み。Javaの Clock.fixed なら固定した時刻を返せる。
• Instant：時間軸上の、ある一つの時点。
• ZoneId：地域の時差・夏時間などのルールを参照するためのID。

同じInstantでも、地域によって現地時刻は違います。店舗の料金を決めるなら、サーバーの置かれた地域に任せず、店舗の地域で判定する必要があります。

もう一つの小ネタ：「22時以上」と「翌朝まで」は違う

学習時の演習条件は「毎日、店舗の現地時刻が22時以上なら深夜料金」。この条件だけなら、午前0時に対象外へ戻ります。「翌朝まで」のつもりなら、終わりの時刻を確認する必要があります。

話の芯：時計を固定しても、仕様の曖昧さは残る。

最後に一言、話すなら

「次にテストを書くとき、自分は何を気にしたいか？」

---

このメモの材料

2026-09-10の学習記録とソフトウェアテストの教材から話題を選びました。記録には、テストの分類での迷い、補足を受けたinterfaceの判断の変化、Clockと店舗タイムゾーンの検討があります。上の小ネタはAIによる技術補足で、本人の過去の発言や実務経験を再現したものではありません。

用語の定義と詳しい例・一次資料は元の教材にあります。対象はSpring Framework 7.0.9、Java SE 25、Mockito 5.20.0。ClockについてはJava SE 25公式資料を2026-09-14に確認しています。