テストを証拠として使う

要件から始める

テストは、特定の主張に対する証拠です。テストの実行が成功しても、ソフトウェアのすべての性質が確認されたわけではありません。テストを依頼する前に、重要な動作と、各確認で検出すべき不具合を特定します。

架空の組織別エクスポート機能では、主な要件はデータの分離です。組織Aの利用者が、組織Bのレコードを受け取ってはいけません。ダウンロードの成功だけを確認するテストでは、この要件を満たした証拠になりません。

要件とアサーションの関係をエージェントに説明させます。テストが大規模になる前に、不足するケースを見つけやすくなります。

単体テストでは、小さな変換を素早く確認できます。結合テストでは、コンポーネント間の動作を確認できます。end-to-endテストでは、デプロイ済みのアプリや実際の利用環境を代表するアプリを通して、重要な一連の利用者操作を確認できます。

必要な証拠を得られる、最も狭い範囲を使います。整形処理の入力をすべて、ブラウザー全体でテストする必要はありません。認可の境界には、実際のルートとデータアクセス経路が必要な場合があります。重要なブラウザー操作には、実際に表示された画面についての証拠が必要です。

すべてのシステムに適した、テストの種類ごとの固定比率はありません。検出したい不具合と、確認を保守する費用に基づいて選びます。

エージェントは、同じ誤解に基づいて実装とテストを書くことがあります。両者が一致していても、要件が満たされない場合があります。

実装が、リクエスト内の組織IDでレコードを絞り込むとします。テストでは、ログインした利用者とリクエストに同じ組織IDを使います。テストは成功します。欠けているのは、利用者が別の組織IDを要求するケースです。

信頼できる実際のIDと認可経路を通る、そのケースを追加してください。常に「許可」を返すmockでは、テナント分離を確認できません。確認できるのは、認可が成功した後の動作だけです。

既知の不具合では、隔離したブランチにある不具合を含むバージョンで、新しい回帰テストを実行します。意図した理由で失敗することを確認します。その後、修正を適用して再実行します。

テストデータを読み込めずに失敗したテストは、まだ業務上の動作の証拠にはなりません。終了コードだけでなく、失敗の内容を調べてください。

広範囲の変更では、mutation testingが役立つ場合があります。選んだコード変更でテストが失敗するかを評価する方法です。費用がかかり、要件のレビューの代わりにはなりません。追加の証拠が重要な判断に役立つ場合に使います。

最終リビジョンで関連する確認を実行します。省略した確認と理由を記録してください。レビューで修正した後は、以前のcommitの結果が適用できない場合があります。

理解しやすいテストを保ちます。重要な条件を隠す大きなヘルパーより、明示的な準備処理とアサーションを優先します。別の不具合を検出せず、保守費用だけを増やす重複した確認は削除します。

レビュー担当者は、テストで何が確認でき、何がまだ不確かかを説明できる必要があります。その説明は、多数のテストがあることより役立ちます。