Kugelblitz

いつ何時誰の挑戦でも受ける!

テスト自動化の5原則

「テスト自動化の8原則」というものが公開されています。テスト自動化は、私も10年ぐらい前からいろいろやってきましたが、きちんと振り返る機会がなかったので、自分なりの原則を作ってみたいと思います。

以下がテスト自動化の5原則です。

  1. テスト自動化の目的は、改修コストの低減とする
  2. 開発プロセスの全てのフェーズで、テスト自動化のメンテナンスが必要となる
  3. テスト自動化を考慮した設計を行う
  4. カバレッジ100%を目指さない
  5. 楽しくやろうぜ

以下は各原則の詳細です。

テスト自動化の目的は、改修コストの低減とする。

元ネタは、

テスト自動化の効用はコスト削減だけではない

となっていて、コスト削減以外のの効用がよくわからないので、「改修コストの低減」と明言してみました。正直なところ、テスト自動化では初期の開発コストを低減することはできない(むしろ上がる)ので、一発使い捨てのアプリとかであれば、別にテストの自動化を考えなくてもいいかと思います。

開発プロセスの全てのフェーズで、テスト自動化のメンテナンスが必要となる

テストコードっていうのは、一度作ったら終わり、というわけではなくて、仕様の変更や、追加に合わせて、随時メンテナンスする工数を見込んでくださいね、ということを謳っています。

テスト自動化を考慮した設計を行う

テスト自動化を行おうと思ったら、テスト自動化が容易になるような設計(テスタビリティの確保)を行っておく必要があります。
例えば、各モジュール間の結合を可能な限り疎にしておいたり(インターフェイスに対するプログラミング)、現在日付をモジュール外側から注入できるようにしておく等です。

また、テスト自動化を考慮されていない既存のアプリケーションに、後からテスト自動化を適用するのは困難です。

カバレッジ100%を目指さない

テストコードが、テスト対象のソースコードをどのくらいカバーしているかを、カバレッジ率といいます。ツールによって、ちゃんとした数値がでてくるので、管理上100%を目指したくなりますが、現実的な工数では実現できませんので、目指さなくてもいいです。

カバレッジが100%は、バグが0であることを意味しませんので、カバレッジ100%にする工数で、別のテストを行った方が、遥かに品質が良いものが完成します。

繰り返しになりますが、カバレッジ100%なんて目指さなくていいです。意味がないテストコードが量産されるだけです。

楽しくやろうぜ

私はテストコードを書くのが面倒です。皆さんはどうなんですかね。
面倒なので、できるだけ楽しくやったほうがいいと思います。テストコードはテスト対象のコードのコーディング規約で縛ったりするべきではありませんし、テストでバグが検出されても、誰かを責めるようなことは禁止です。

バグ抽出率とかを目標にするのもバカっぽいのでやめましょう。

Pocket

他の記事