testing-changes

変更のテスト

必須の前提知識： principal-engineering スキル。テストの書き方は writing-unit-tests が扱い、このスキルでは変更に必要なテストを定めます。

概要

テストとは、振る舞いに関する主張を実行可能な形にしたものです。テストに手を加えずに振る舞いを変える変更は、誰も記録していない主張です。そこから、動作しないはずのコードに対してテストスイートが成功することと、テストやゲートが一度も実行されないことという、2つの失敗が生じます。

変更に必要なテスト

1. 振る舞いの変更と同じ変更で、テストも変更します。 振る舞いを変える変更でテストの差分が空であれば、スタイル上の好みではなく、レビューで指摘すべき問題です。純粋なリファクタリングで必要なのはその逆の証明です。既存のテストを変更せずにすべて通過することが、リファクタリングであることの根拠になります。
2. バグ修正には回帰テストを添えます。 テスト名はチケットではなく、障害の原因となった振る舞いに基づいて付けます。作成者は、修正前のコードでは失敗し、修正後のコードでは成功するという両方を示します。一度も失敗しなかった回帰テストが証明するのは、コンパイルできることだけです。
3. シナリオは具体的にし、表面化したエッジケースを含めます。 根拠の確認やレビューで見つかったエッジケースは、名前を付けてテストに含めます。正常系だけではデモをテストしているのであって、変更をテストしていることにはなりません。変更のリスクが失敗経路にある場合は、失敗経路をテストします（handling-failures では、ログに記録された型付きの失敗が必須です。その表面化もテストで確認すべき振る舞いです）。
4. 各タスクには、対象を絞った検証コマンドを含めます。 タスクには、この変更を証明する検証コマンドを明記します。そのコマンドは単独で実行でき、レビュー担当者が実行できる場所に記載します。「テストスイートが通過した」という説明では、スイートがカバーしていない内容を何も証明できません。
5. アサーションは違いを判別できるものでなければなりません。 変更の有無にかかわらず通過するテストは何も証明しません。コードを一度壊し、テストが失敗することを確認してから元に戻します。違いを判別できないアサーションがあると、壊れた振る舞いがあってもテストスイートが成功し続けます。
6. 整合性を保つ必要がある集計には、不変条件を検証するテストを加えます。 プロジェクトで宣言されたクリティカルパス（principal-engineering のリスク段階を参照）上にあり、他のデータを合計、導出、または複製するものには、個別の例だけでは不十分です。テストで整合性そのもの（保存パターン）をアサートし、集計値が生のレコードから導かれる値と一致することを確認します。

失敗したテストのルール

自分が管理するゲートで失敗したテストは、決して黙らせず、修正します。アサーションを弱めたり、テストを削除したり、出荷のためにスキップ扱いにしたりすることは、検出済みの欠陥を未検出にすることです。テストの変更が正当なのは、テストが以前の誤った振る舞いをアサートしており、そのことを変更で明示する場合に限られます。まず原因の所在を明らかにし、その後、誰のテストかにかかわらず修正します。「以前から存在した」は注記にはなりますが、言い訳にはなりません（verifying-before-done を参照）。

変更に必要のないテスト

• 到達不能なエッジケースのテスト（scoping-changes を参照。起こり得ないことを防ぐのは、善意の死んだコードです）。
• フレームワーク内部や生成コードのテスト。それらを使うコードは、自分が管理する境界でテストします。
• テストファーストのプロセス。テストを先に書くかどうかはワークフローの問題です（プロジェクトでテストファーストのワークフロースキルが導入されている場合は、そのスキルが定めます）。このスキルが定めるのは、どの順序で作られたかにかかわらず、変更を出荷する時点で存在すべきものです。

よくある間違い

• 「テストするには小さすぎる」。1行の変更でも、どのテストもカバーしていない振る舞いに影響し、誰かが監査するまで回帰が見過ごされます。
• バグを再現せずに修正だけをテストする。修正前に失敗することは、テストが欠陥を検出するという証明の半分です。
• 感覚でカバレッジを数える。「Keeping documents true」の下にある、技術ライター向けプラグインの technical-writing/references/truth.md に記載されたドキュメントカバレッジの数え方と同じルールで、変更した振る舞いの数と、それぞれに名前を付けたテストの数を照合します。
• 何に対しても違いを判別しないテストを追加する。もっともらしい欠陥があっても失敗し得ないアサーションです。これは、変更前後のどちらでも意図的に成功し、隣接する変更されていない振る舞いが過剰に修正されるのを防ぐ、正当な固定テストとは異なります。固定テストでは、その目的を明示します。