tdd

TDD によるバグ修正

対象は TypeScript リソースとその NUI です。テストは各リソースのテストランナーで実行され、コードが使用するネイティブ関数と @overextended/ox_lib の呼び出しはモックされるため、FiveM サーバーは必要ありません。

バグに対して明確で手軽なテスト方法がある場合は、本番コードを変更する前に、不具合のある動作をテストで再現できるようにしてください。目標は、修正前は失敗し、修正後は成功する、対象を絞った回帰テストです。

テストの実施が現実的でない場合、無理にテストを作成しないでください。利用可能なテストで大規模なハーネスの設定、壊れやすいモック、時間のかかるエンドツーエンドの環境、本番環境専用の状態、曖昧な再現手順、または無関係なフィクスチャの大幅な変更が必要になる場合は、新しいテストの追加を見送り、代わりに最も適した検証方法を使ってください。

ワークフロー

1. バグを把握します。 期待される動作、現在の動作、影響を受ける経路、そして観測可能な最小の再現方法を特定します。
2. 実行可能な最小範囲のチェックを選びます。 そのコード経路ですでに使われている、最も近い単体テスト、コンポーネントテスト、統合テスト、または回帰テストを優先します。実用的なテスト方法がすぐに見つからない場合は、ワークフローを満たすためだけに一からテストを作成しないでください。
3. 失敗するテストを先に書きます。 バグを検出できたはずの、対象を絞った最小限のテストを追加します。テストでは現在の実装をなぞるのではなく、期待される動作を表現してください。
4. 修正前に新しいテストを実行します。 想定した理由で失敗することを確認します。成功した場合や、無関係な理由で失敗した場合は、実装を編集する前にテストまたは再現方法を修正してください。
5. バグを修正します。 周辺の契約を保ちながら、期待される動作を実現するための最小限の本番コードの変更を行います。
6. 回帰テストを再実行します。 テストが成功することを確認します。

失敗するテストの実施が現実的でない場合

代わりに、実行可能な範囲で最も適した回帰チェックを使ってください。たとえば、対象を絞ったスクリプト、NUI の開発サーバーに対するブラウザー自動化、ログのアサーション、またはバグが型エラーの場合の tsc --noEmit です。

質の悪いテストを追加するくらいなら、新しいテストは追加しないでください。モックのテストが中心になっている、現在の実装の詳細を前提としている、タイミングや無関係なグローバル状態に依存する、小さな修正に高コストな環境を必要とする、または修正の確認後すぐに削除するようなテストは質が悪いテストです。

ガードレール

• 誤った実装に合わせてテストを変更しないでください。
• 期待される動作が本当に変わり、その理由が明確な場合を除き、既存のアサーションを弱めないでください。
• 回帰テストはバグに対象を絞ってください。フィクスチャを広範囲に変更したり、無関係なテスト範囲を拡大したりしないでください。
• バグが不安定に再現する場合は、可能な限りテストを決定的にし、固定するシグナルを記録してください。
• バグがより広い種類の障害を示している場合は、まず対象を絞った回帰テストを追加し、その後、関連する追加テストを検討してください。

最終回答

結果だけでなく、根拠を報告してください。

• 修正前に失敗したテストまたは実行可能なチェックと、その失敗内容を示します。
• 修正後に成功したテスト実行と、あわせて行った関連する検証を示します。
• 修正前の失敗を確認できなかった場合は、その理由と、代わりに使った最も適した回帰チェックを説明します。