テストの方針
自分のノート。書籍第11〜14章の要約は
テスト に切り出してある。
テストスイートが健全なときとそうでないとき
同じ観点を両側から並べたもの。右に寄っているなら手を打つ。
重複
| 健全 | 不健全 |
|---|
| 1つの挙動に対して自動テストは1つだけ | 過去に何回も同じテストを手動で行っている |
| バージョンアップ時は自動テストだけでよい | バージョンアップのたびに膨大な手動テストが必要 |
| テストデータが実際に即しているので自動テストだけでリリースできる | テストデータが実データと違うので、ステージングでも本番でも同じ手動テストをやる |
| ブラウザ毎・言語毎の同じテストは毎回自動テストが行う | ブラウザ毎・言語毎に同じテストを手動で行っている |
| — | 自動テストの信頼が低いので、自動・インテグレーション・手動と何層にも重複したテストが存在する |
バグが見つかるフェーズ
| 健全 | 不健全 |
|---|
| 開発中の自動テストで見つかるのでリバートされない | 自動テスト以降で見つかるのでよくリバートされる |
| プルリクにもリリースにもバグが入り込まない | プルリクにもリリースにもバグが入り込む |
| 本番リリース後に問題が発覚しない | 本番リリース後に問題があって初めて気付く |
| 原因究明の手動デバッグが不要 | 原因究明のために手動デバッグが必要 |
| 緊急リリースがない | 緊急リリースがよくある |
| どのリリースが原因かの切り分け作業が要らない | 切り分け作業が必要になることがある |
| リリースをプルリクと別管理しなくてよい / 手順がシンプル / すぐリリースできる | リリースが別管理で高コスト / 手順が多い / 時間がかかる |
自動テストの信頼性
| 健全 | 不健全 |
|---|
| 変化を可能にする観点で設計されていて、プロダクトを変えやすい | そう設計されておらず、変更の障壁になる |
| スケールと高速な変化に必要な存在。毎日何千ものリリース、毎週数千万行の変更が可能 | 障害になる。そのどちらも不可能 |
| 挙動を変えないリファクタリングではテストが失敗しない。リファクタリングを促進する | 挙動を変えなくても大量に失敗する。リファクタリングの障壁 |
| 新機能追加・リファクタリング・大規模設計変更のときに間違いを捕捉できる | 捕捉できない |
| 新規機能のテストを書く過程で設計の改善やケース不足に気付ける | 気付けない |
| 生産性を上げる。費用対効果が高い | 生産性を下げる。ない方が費用対効果が高い |
| 全部成功していれば実際の挙動は常に正しい。バグがあるときだけ失敗する | 全部成功しても挙動がおかしい。バグがなくても失敗する |
| バージョンアップ時に手動テストが不要で、素早く頻繁に上げられる | 手動テストが必要で、バージョンアップが遅れがち |
| 最新の挙動と一致したドキュメントになる | ユースケースを網羅できておらずドキュメントにならない |
| テストコードレビューで挙動を担保できる | 担保できず、別途挙動を確認するレビューが要る |
いいテストの条件のうち、自分の基準
挙動の変化と成功・失敗が対応している
挙動がおかしくなったときにちゃんと失敗する
レビュー時にソースを書き換えておかしな挙動にしてもちゃんと失敗する
大規模リファクタしても挙動が変わらなければテストコードを書き換える必要がない
APIのフレームワーク・言語・ライブラリが変わっても挙動が同じなら失敗しない
手動テストと同じ信頼性
自動テストだけで、手動テストは不要なくらいの信頼性
失敗時の依存先が明確
自チーム内の複数モジュールを含めたテストの場合にどの依存関係先が原因かすぐに分かる
現実に即している
公開されているものを使う側の視点でテストが書かれている
APIならそのAPIを使う側と同じアクセスの方法でテストされている
テストデータが実際のユースケースのデータ
個人情報はマスキングする
自動テストと実際に手動で動かすチェックの信頼度が同じかどうか
正常に動くソースのみコミットされる
コミット前にテストが実行される
テストが成功したもののみコミットできる
静的解析ツールが整備されている
テストフレームワーク用の静的解析ツールが整備済みであるか
設定ができるだけデフォルトであるかどうか
設定がバージョンアップを想定しているかどうか
テスト対象とだぶり
ライブラリはテストが書かれている
他のクラス用のクラスのテストは書かず、使っているクラス側の挙動のテストに含める
テストの構造を実装の構造に合わせずに、挙動がテストされているか
実装とテストコードが互いに独立しているかどうか
エンジニア視点ではなく、ビジネス視点でテストが書かれているか
依存の置き換え
速度と決定性に影響があるもの(別サーバーや外部組織のDB等ネットワーク接続を確立)は使わずにスタブを使う
テスト対象クラスの多数の依存関係コードや他のクラスへの参照はテストダブルにはしない
スタブにするのは他チーム・他社の依存先だけ
自チーム内の外部依存先は実データにする
データはシードデータとしてリポジトリ管理されている
オブジェクト生成機能はハードコードではなく、ファクトリーメソッドかDIで分離して、本番と同様のものを使う
オブジェクト生成がハードコードされておらず、コンストラクタが改修されたときにテストコードの保守が不要
関連
- テスト — 書籍第11〜14章の要約
- コードレビューの進め方 — テストが読めるかどうかもレビューの対象
- Go — テストコードをコードと同じパッケージに置く言語での具体