Testing Zen - ソフトウェアテストの技法 第2版

『ソフトウェアテストの技法 第2版』を読んだ。

テストには一見相反した態度が必要になる。改めてそう思った。真剣にバグを見つけようときめ細かくテストしつつも、結果的にバグが出ないことも成功だからだ。

われわれの考え方からすると，ひと塊のソフトウェアに対する，よく構成され実行されたテストは，修正できるエラーをみつけたときに成功と見なし．そしてその同じテストによって．これ以上エラーがみつからないことが結果的に確立されたときにもまた成功と見なす．

気をつけないといけないのは、バグが出なかったという結果は成功だけれど、バグを出さないという目的でテストしているわけではないことだ。それならテストを粗くすればいい。極端な話、テストしなければ出てくるバグは皆無だ。

できるだけ多くのバグを見つけようとしなければ、テストする甲斐がない。頭では理解しても、これがなかなか難しい。例えば、一刻も遅れも許されないという状況で、バグを見つけようと徹底できるだろうか。見つけてしまえば、修正～再テストが必要になって、ますますスケジュールがタイトになるというのに。

テストとは，エラーをみつけるつもりでプログラムを実行する過程である．

嘘か誠か、テストコードを動かすだけ動かして、全く結果を見ていなかったプロジェクトがあったなんて話が、Martin Fowler's Blikiにある。4 Phase Testでいうとexerciseまでやってverifyしなかっただなんて。

しかしながら、そのJUnitのテストコードにはassertionが一切含まれていなかった。
Martin Fowler's Bliki in Japanese - AssertionFreeTesting

これは極端な例にしろ、ともすればテストが通るようにテストデータを設計しがち。最初はそれでいいと思う。まずHappy Pathを通すのは悪くない。『ソフトウェアテスト 293の鉄則』にもこうある。

鉄則287 製品の成熟度に応じてテストせよ

でも、それだけじゃ明らかに足りない（どこまでやれば十分か、は明らかじゃないけれど）。