駆け足で Google から学ぶテスト設計の指針

Transcript

1. 駆け足で Google から学ぶテスト設計の指針
2. 「Googleのソフトウェアエンジニアリング」本の 11 ~ 13 章を読み、テスト・ユニット テストに関する重要な点を学んだ。 11章：テスト概観 12章: ユニットテスト 13章: テストダブル
3. 学んだこと テスト文化とその意義 テストの分類と設計方針 曖昧さをなくすテストの分類方法 理想のテストピラミッド 保守性の高いユニットテストを書くためのプラクティス テストダブルの活用方法 抽象データ型との繋がり
4. テスト文化とその意義 テストを 開発プロセスの中心に据えた自動テスト文化 がもたらすメリット デバッグの減少 変更への信頼の増大 ドキュメンテーションの改善 レビューワーの負荷軽減 良い設計につながる 高速で高品質なリリース 開発プロセスの中心の据えた自動テスト文化 を成り立たせる重要な要素 エンジニアが日常的にテストを回す仕組み 破綻したテストをすぐに修正する文化
5. テストの分類と設計方針
6. 曖昧さをなくすテストの分類方法 「ユニットテスト」とはどんなテストを指すのか、解釈に幅がある。 → 規模 (実行に要するリソース) で小・中・大、範囲 (検証している特定のコードパス) でユニット・インテグレーション・E2Eに分類可能 この規模の分類と範囲の分類を掛け合わせることで 3×3 のマトリクスが得られる。 小テスト 中テスト 大テスト 小範囲 中範囲 大範囲 これでテストの分類に関する曖昧さを減らした議論が可能に
7. 理想のテストピラミッド Google では、 ”エンジニアリング生産性” と “製品の信頼性“ の観点から、テストスイート の設計において以下の指針がある 引用: Google ソフトウェアエンジニアリング
8. ユニットテスト中心の構成がもたらすメリット １テスト当たりの実行時間が短く、フィードバックサイクルが高速 素早くかけるため、テストカバレッジが高水準になりやすい 各テストの内容・目的が単純で、失敗した際に間違っていた理由を理解しやすい
9. 保守性の高いユニットテストを書くためのプラクティス 保守性の高いユニットテストをかけなかった場合、エンジニアの生産性が低下してし まう。 この保守性の高いユニットテストを書くために重要なポイント 脆いテストを防ぐ 明確なテストを書く DAMP なテストコードを目指す
10. 脆いテストを防ぐ 脆いテストとは 実際のバグを全く持ち込んでいない無害かつ無関係な変更に反応して壊れるテスト 理想のテストとは テスト対象システムの要件が変化しない限り、書かれた後は二度と変更が必要ないテ スト この理想のテストを書くためのプラクティスは 公開 API に対するテストを書く ことと ステートテストを書く こと。
11. 公開 API に対するテストを書く 公開 API に対するテストを書くとは、つまり テスト対象システムのユーザーが呼び出 すのと同じ方法でシステムを呼び出すテストを書く こと。 適切な 公開 API を定義することが重要だが、明確な観点があるわけではなさそう。 (書籍には、経験に基づくユニットに適切な範囲を定義し、それにより公開 API とみな されるべきもの定義する方法が紹介されていた)
12. ステートテストを書く テスト対象システムが期待通りの挙動を行うか検証する2つの方法 ステートテスト システムのメソッドを呼び出した後に結果が何 (what) であるかを見る インタラクションテスト どのように (how) システムがその結果に到達しかたをチェックする 通常、how をチェックするためにシステムの内部的な実装の詳細に依存するインタラ クションテストは脆くなりがち。
13. 明確なテストを書く 明確なテストとは、その存在目的と失敗理由が、失敗の原因を究明するエンジニアか ら見て明確となるテスト 明確なテストを書くプラクティスは以下の通り テストは完全かつ簡潔にする テストの本体部分に、重要でない情報や紛らわしい情報は全く含まずに、テ ストを理解するのに必要な情報を全部含むテスト メソッドではなく、挙動をテストする テストにロジックを入れない 明確な失敗メッセージを書く
14. DAMP なテストコードを目指す DAMP (Descriptive And Meaningful Phrases) とは、説明的かつ意味がわかりやすい言い 回しがされていること。 少々の重複は、それがテストを単純かつ明確なものにする限り問題ない。 逆に、共有する価値があるコードは以下の通り 共有値 初期設定の共有 ヘルパーメソッドと検証メソッドの共有 テストインフラストラクチャーを定義 例: JUnits
15. テストダブルの活用方法 テストダブルのメリット コードの複雑性が増した際にユニットテストを書きやすくする 本物の実装よりも軽量なため、迅速に実行可能な小テストを書きやすくなる テストダブルのデメリット テストダブルを利用するには、コードベースがテスト可能なように設計されている 必要があり、設計コストがかかる (テスト可能性) テストダブルを不適切に使用すると、テストが脆く、複雑になる可能性がある (応 用性) テストダブルの挙動を本物の実装とかなり似せておかないと、実際にテストした い内容が観れるとは限らない (忠実性)
16. テストダブルの種類と特徴 フェイキング 本物の実装より高速な、本物の実装同様に振る舞うシステム 本物と同じAPI契約を守ることが必須 スタビング 特定の戻り値や例外を返すだけの実装 複雑なシナリオやエラーケースを手軽に再現できる 多用すると、テストが不明確になる & 脆くなる モック 関数がどのように呼ばれるかを、その関数の実装を実際に呼び出すことなく 検証する方法 内部実装の詳細に依存しがちで、最も脆くなりやすい
17. 本物の依存かテストダブルを使うかの判断基準 観点 実行時間 本物が遅くてフィードバックが阻害される場合はテストダブルを検討 決定性 外部サービスへの依存でたびたび失敗するならテストダブルに置換 依存関係の複雑さ 本物を組み込むために膨大なセットアップが必要ならフェイク優先 方針 まず本物の依存を使い、遅い・不安定になったらフェイク→スタブ→モックと段階的 に導入
18. 抽象データ型との繋がり 以前の関ジャバで 抽象データ型 に関してお話しさせていただいた。 この考え方に則ってテスト対象を設計することで、良いテストが書きやすくなると感 じた。
19. 抽象データ型に基づいた公開 API を用いることで、脆いテストが書きづらくなる 公開 API に依存することが必ず実装の詳細に依存しないとは限らない 抽象データ型に基づいてクラスを設計することで、公開 API が実装の詳細を 外部に露出しなくなり、脆いテストが書きづらくなる 検査すべき挙動 = 公理と捉えることができて、ユニットテストで何を担保するべ きかが明確になる メソッドではなく挙動をテストするべし、の挙動が公理から見えてくる 契約が明確になることでフェイクで何を実装するべきかがわかりやすくなる 事前条件・事後条件を記述するため
20. まとめ 1. 自動テストを大事にする文化がエンジニアの生産性を向上させる 2. 良い自動テストを書くための指針を理解する 3. 良いテストを書くためには、良い設計が必要
21. 参考文献 Google ソフトウェアエンジニアリング（11–13章） オブジェクト指向入門 第2版 原則・コンセプト