assert-what-the-generator-found

ある表現を読み込み、別の表現を出力するものを書いた場合に当てはまる。スキーマダンプ、リファレンス抽出器、マイグレーション、スクレイパー、インデックスビルダーなど、出力量が多すぎて誰も全体を読まないもの全般が対象だ。

目視で確認できる単一の値を返す関数には当てはまらない。ここでのリスクは、「見た目は正しそうだ」がその出力に対して行われる唯一のレビューになってしまうほど出力が大きい場合に固有のものだ。

1. テストを書く前に、件数を明確にする。コマンド、行、ファイル、フィールドが何個出力されるべきか。その数字はジェネレーター以外の場所——ソース、ドキュメント、手作業のカウント——から得ること。
2. その件数、またはその下限を検証する。assert result ではなく assert len(groups) >= 10 とする。
3. 存在するはずだと分かっている、具体的で名前のある項目の存在を検証する。3〜4個で十分であり、異なる形の入力から選ぶこと。
4. ジェネレーターが分類を行うなら、各クラスが空でないことを検証する。すべてを一つのバケツに入れてしまう分類器の不具合は、これで捕捉できる。

件数を厳密に固定すると、テストは保守の手間になる。正当に追加されたコマンドのたびに赤くなってしまうからだ。下限(>= 10)と名前付き項目の組み合わせを優先し、厳密な件数は、決定なしには本当に変わってはならないものにだけ取っておくこと。

また限界もある。この種のアサーションは、ジェネレーターがカテゴリ丸ごと落としたことは捕捉するが、ある項目の1つのフィールドだけが間違っているケースは捕捉しない。そうではないふりをすることも、それ自体が一種の過信である。