よく考えてみたら「テスト」について勉強したことなかったなと思って、本を読んでみた。
- 作者:リー・コープランド
- 発売日: 2005/11/03
- メディア: 単行本
本の解説
「はじめて学ぶソフトウェアのテスト技法」は、バグを効率的に発見するためにテストをどう行えばよいかという問に答える本だ。 テストコードの保守性を上げるにはどうしたらよいか、という問には答えてくれないので、その問題意識を持つ人は別の本をあたったほうが良いと思う(良い本があったら教えてください)。
本書は、以下のブラックボックステストの技法を解説している。
我々がテストを書くときに無意識に実践している項目もある。例えば「同値クラステスト」は、ほとんどのプログラマーは無意識にやっているはず。 ただ、他のテスト技法に関しては、実践したことのないものばかりだった。
これまでは、テストでバグを発見できる気がしなくてすごく気持ち悪かったんだけど、この本を読んだことである程度自信を持ってやれそうな気がしてきた。
あと、すごく重要なことなんですが、この本はかなり読みやすいです。 昔似たような本を読んだときはとにかく退屈で、10ページぐらい読んでやめてしまったんだけど、この本は一人でもサクサク読みすすめられました。
面白かったところ
同値クラス・境界値
個人的には同値クラスと境界値が大事な発想だと思った。
テストっていうのは、原始的にはありうる全ての入力パターンを試して正しく動くことを担保しないといけないと思うんだけど、現実的にはそれは無理だ。 入力がenumとかで有限のパターンしか取らないなら可能かもしれないけど、整数とか実数が入力パラメータに入ってくるとオシマイだ。 そこで導入される考え方が「同値クラステスト」と「境界値テスト」だ。
振る舞いが「非線形」に変化する領域ごとに入力をグルーピングして、そのグループの「端の値」と「代表的な値」をテストしましょうね、というのが同値クラス・境界値テストだと自分は理解した。 同値クラス・境界値の発想を理解することで、整数とか実数とかの、無数の値を取る入力に対しても網羅的にテストが書けることになる。 このことによって、逆に「網羅的にテストを書こう」という気持ちになれることを発見した。
これまでテストを書くときは、以下のパターンでテストを書くことが多かった。
- 網羅性を気にせず、ド正常系を1つと、思いつく限りの異常系をテストする
- 正常系に属する範囲から入力をランダムに選んでテストする
これは、どうせ網羅的にはテストを書けないのだから網羅性を担保するのを諦める、という発想が根底にある。
網羅的にテストを行う手法を理解したことで、網羅的にテストを書こうという気持ちになれる。
また、同値クラスと境界値を前提として様々なテスト技法が存在している。 例えば、デシジョンテーブルは同値クラスと境界値を前提として入力の網羅性を担保したいときに使う技法だし、ドメイン分析テストは同値クラス・境界値の拡張だ。 そういう意味でも、同値クラスと境界値を理解することは重要な雰囲気を感じる。
ペア構成テスト
ペア構成テストも面白い。 これは、単体では問題なく動くコンポーネント同士を組み合わせたときにバグるのを発見する手法だ。 組み合わせるコンポーネントの種類に対して、コンポーネントの組み合わせの数は指数的に増えていく。 そのため、全てのコンポーネントの組み合わせパターンをテストするのは実質的に不可能だ。 この問題を解決するために導入される手法がペア構成テストだ。
経験則として「組み合わせでバグるのは、2つのコンポーネントを組み合わせたときにバグるのがほとんどで、3つ以上のコンポーネントを組み合わせたときだけバグるというのはほとんどない」ということが知られているらしい。 つまり、コンポーネントの全組み合わせを調べる必要はなく、全てのコンポーネントがペアを組んだことがあるような組み合わせに絞ってテストをすれば、それだけでかなりの確率でバグを発見できる、ということだ。
「全てのコンポーネントがペアを組んだことがあるような組み合わせ」を生成するソフトウェアが世の中には存在するので、それを使ってテストする組み合わせをリストアップすればいい。 これによって、全組み合わせをテストするのに比べて格段にテスト対象を減らすことができる。
ただ、自動テストをするという観点からは、多くの場合は全組み合わせをテストすることは可能だと思う。特に正常系をざっとみるだけであれば、テストケースを自動生成してエラーがthrowしないことをチェックするのは簡単なはずだ。 一方で、各組み合わせに対して詳しい挙動をチェックしようと思ったら、ペア構成テストは自動テストにおいても有効な手法だと思う。
状態遷移テスト
これまで状態遷移をテストしたことなかったけど、いざやることになったら多分どこから手を付けたらいいかわからんとなっていたと思う。 この本には状態遷移をテストする方法がいくつか紹介されていて、それぞれどのぐらい偉いテストなのかということが書いてあってよかった。 重要な状態遷移なら気合を入れて偉いテストを書き、どうでもいいやつならざっくりテストを書く、ということができると思う。
まとめ
「はじめて学ぶソフトウェアのテスト技法」は面白い本だった。 雑にテストを書いてるソフトウェア開発者の人は一度読んでみると面白いと思う。
それはそれとして「いいテストコードの書き方」「テストが書きやすい設計をする方法」とかの知見はこの本からは得られないので、オススメの本がある人は教えてください(クリーンアーキテクチャは読みました)。
これは読書ノートです： 初めて学ぶソフトウェアのテスト技法 - genya0407のメモ
NOTE:
本書はブラックボックステストの手法だけでなく、ホワイトボックステストの手法も取り上げています。 しかし、ホワイトボックステストの扱いは小さいし、「ホワイトボックステストに拘るな」みたいな記述があったし、本体コードにゴリゴリに依存したテストコードの保守性はものすごく低いことが予測され、実際に業務で書くことはあまり無いだろうと思ったので、読み飛ばした。
とはいえ、「この分岐ってテストされてないけど大丈夫かな」のような発想でテストケースに気づけることもあると思うので、なんとなく意識するぐらいのことはしてもいいのかなと思った。
