Pythonによるテスト駆動開発, 3rd Edition

第27章　速い テスト、遅いテスト、そして熱い溶岩

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

データベースは溶岩だ！

ケイシー・キンジー

本書も終わりに差し掛かり、 このToDoアプリとそのテストとの旅も終盤だ。 これまでのテスト構造を振り返ろう：

• 我々はSeleniumを用いた機能テストスイートを持ち、アプリ全体が実際に動作することを検証している。 これまでに幾度か、FTが壊れたコードのリリースを防いでくれた——壊れたCSSであれ、ファイルシステム権限によるデータベースの破損であれ、メール統合の不具合であれ。

• またDjangoテストクライアントを用いた単体テストスイートも保有しており、モデル・フォーム・ビュー・URL、さらには（ある程度）テンプレートのコードをテスト駆動開発できる。 これによりアプリの増分開発が可能となり、信頼性を持ってリファクタリングを実施でき、高速なユニットテスト/コードサイクルを支えている。

• インフラにも相当な時間を費やした。 デプロイを容易にするためDockerでアプリをパッケージ化し、 プッシュ時にテストを実行するCIパイプラインをセットした。

しかし、一冊の本に収まるほどシンプルなアプリである以上、 このアプローチには必然的に制限や簡略化が伴う。 本章では、実世界の大規模で複雑なアプリケーションに移行する際、 テストの原則をどう発展させるかについて話したい。

なぜデータベースが「熱い溶岩」だと言われるのか、その理由を「発見」してみよう。

なぜテストするのか？効果的なテストの要件

testdesiderata.comでは、Kent BeckとKelly Suttonが テストに求められる理想的な特性（desirable characteristics）をいくつか提示している：

• 分離性：テストは実行順序に関わらず同じ結果を返すべきだ。

• 構成可能：異なる変動要因を個別にテストし、結果を組み合わせられるべきだ。

• 決定論的：何も変わらなければ、テスト結果も変わるべきではない。

• 高速性：テストは素早く実行されるべきだ。

• 記述容易性：テストは、テスト対象のコードのコストに比べて、安価に記述できるべきだ。

• 可読性: テストは読者に理解可能で、そのテストを書いた動機を喚起するものであるべきだ。

• 動作依存性: テストは対象コードの動作変化に敏感であるべきだ。動作が変わればテスト結果も変わるべきである。

• 構造に依存しない：コードの構造が変わっても、テストは変わるべきではない。

• 自動化: テストは人間の介入なしに実行されるべきだ。

• 具体的であること：テストが失敗した場合、その原因が明らかであるべきだ。

• 予測性: テストが全て成功した場合、テスト対象のコードは本番環境に適していると言える。

• 信頼性を与える：テストに合格すれば、信頼性が生まれるべきだ。

本書ではこれらの要件のほとんどを扱ってきた： Djangoテストランナーへの移行時に分離性について論じた。 第21章の自動車工場例で構成可能性について論じた。 given-when-then構造やFTにおけるヘルパーメソッド実装時に可読性について論じた。 モックに関する章を含む複数箇所で実装ではなく動作をテストすることについて論じた。 フォームの章では構造について議論した。 高レベルなビューテストが低レベルなフォームテストより自由にリファクタリングできることを示した時だ。 ...