はじめに
テスト自動化において、あるあるなエピソードを紹介します。
カバレッジは高いがassertが抜けている
テストスクリプトを書いているときに、カバレッジが高いことに安心してしまい、十分なassert文を書けていないことがあります。
ソフトウェア内の経路を解析してテストカバレッジを測定するツールは、テストスクリプトが実際に期待通りにソフトウェアの妥当性を確認しているかどうかを保証するものではありません。
高いテストカバレッジは、テストスクリプトがソフトウェアの多くの部分をカバーしていることを示すだけであり、十分なテストを行っていることを保証するものではありません。
過不足なく assert 文を使って適切に妥当性を検証することで、はじめて自動テストが意味を持ちます。
テストデータが読みにくい
テストデータを直接記述しているテストスクリプトをしばしば見かけます。
スクリプト内にデータが含まれるとデータ構造とスクリプトの制御シーケンスが混在してスクリプトが読みにくくなります。
データはスクリプトから分離して外部ファイルに記述することで、データの読みやすさを維持しつつ、スクリプトの保守性を高めることができます。
テストスクリプトが長い
1000行を超えるテストスクリプトとか・・・。
1つのテストメソッドの中で複数のテストシナリオを実行していると、テストスクリプトが長くなりがちです。
また、テスト対象とするソースコードの複雑度が高いと、テストスクリプトも複雑で長くなりがちです。
本来は、、ソフトウェアをリファクタリングしたり、1つのテストメソッドでテストするシナリオを1つに絞るなどして、テストスクリプトを短く保つことが望ましいです。