開発日報

窓際エンジニアの開発備忘。日報は嘘です。

【忘備】グーグルのソフトウェアエンジニアリング ~ ユニットテスト① -テストの保守性- ~

Googleにおけるユニットテストの定義

Googleがテストを分類する際に使用する2つの軸

  • テスト規模:テストにより消費されるリソース、テストが実行されている内容に焦点を当てる
  • テスト範囲:テストが検証を意図する実装コードの量

また、Googleにおけるユニットテストの定義は

  • ユニットテスト:単一のクラスorメソッドのような相対的に狭い範囲のテストを指す

自動テストの目的 → 生産性

自動テストの最重要目的は「バグの防止」だが、それに続いて重要な目的として「エンジニアの生産性の改善」がある。

優れたユニットテストは、開発の生産性を最適化するのに適した以下の属性を持つ。

  • 小規模傾向で高速・決定性であり、開発者が自身の開発フローの一部として頻繁に実行し、そのフィードバックを直ちに得ることができる。
  • テスト対象コードと同時に書くのが容易。作業中のコードにテスト対象を絞れる。
  • テストカバレッジが高水準。
  • テスト失敗時に何が間違っていたか理解しやすい。
  • ドキュメンテーション及びコード例の役割を果たす。
    • テスト対象のシステム部位の使い方と、意図している動作が理解できる。

また、Googleでは書かれるテストの80%がユニットテスト、残りの20%がより広範囲なテストであることを推奨している。

テストの保守性

肥大化したテストのメンテナンスって大変だよね。グーグルクラスの規模だと各テストが密に結合していると一か所の変更が膨大な数のテスト失敗を生み出してしまう、、という苦難を味わったこともあるそう。

テストは「とにかく動作すること」が大事。これを阻害するテストとして、、

  • 脆いテスト:バグのない無害な修正・変更を入れているのに、無関係な個所のテストが壊れる
  • 不明確なテスト:テスト失敗時に間違っている点、修正方法、テストが何を意味するかが分からない