Laravel でテストを書くときの方針として妥当なのはどれですか。
ルートを叩いてレスポンスとDBの状態を検証する Feature テストが中心です。Laravel はこれが書きやすく費用対効果が高い。専用のテストDBと RefreshDatabase を併用します。
面接官が見ているのはテストとDBの関係を理解しているか。
よくある答えと、面談でどう見られるか
- ルートを叩いてレスポンスと DB の状態を見る Feature テストを中心に、テスト用DBを分ける
Laravel は Feature テストが書きやすいので費用対効果が高い、という判断は妥当です。 - すべてのクラスに Unit テストを書くことを最優先する
網羅性は上がりますが、コストの割に「壊れていないこと」の保証が薄くなりがちです。 - 本番と同じ DB に接続してテストする
本番データを壊します。専用のテストDBを使います。 - テストは書かず、手動確認で担保する
既存コードに手を入れるたびに全画面を手で確認することになります。持続しません。
面接官は何を見ているか
- Feature テストと Unit テストの違いに触れた
- テスト用DBを本番と分けていた
- RefreshDatabase 等のトレイトに触れた
模範解答
主に Feature テストを書いていました。ルートを叩いてレスポンスとDBの状態を検証する形です。Laravel は Feature テストが書きやすいので、費用対効果が高いと思っています。DBは専用のテストDBを用意し、RefreshDatabase トレイトで各テストの後に状態を戻します。
ここからどう深掘りされるか
この問いに答えられた場合、面談は次の質問に進みます。
観点をすべて押さえられた場合
RefreshDatabase が速いのはなぜですか。それが使えない場面はありますか。一部しか触れられなかった場合
テストが1本も無いコードに機能を追加することになったら、どこから手をつけますか。