テストについてつらつら書いてみるよ

ども、とうとう入社10年目になりました。
エイプリルフールですが嘘は書きませんよ。--);　
最近はマトリックス形式のチェックリスト作ってshunit2でシェルのユニットテストなんかやってます。

テストについて思うこと教えてもらったことなどをつらつらと書いてみたいと思います。

テストは重要ですが、嫌われる作業ですね。面倒くさいしね。ただテストの分野ってすごくブルーオーシャンな気がするんですよね。TDDをのぞけば開発言語ってそんなに関係無いし。

テストって言っても幅広いので、ここではアジャイルテストの4象限ならぬオレオレテストの4象限を紹介しようw

横軸はテスト粒度を意味する。左から右にいくほど大きくなる。多分一番細かいのはメソッド単位で、クラス、ユースケース（単機能）、シナリオ（複数の機能を組み合わせたもの）と大きくなっていく。

縦軸は自動化具合を意味する。下から上にいくほど手動になる。テスト対象によって自動だったり手動だったりするだろう。また自動といっても３種類あると思っていて、それは準備、実行、結果確認だ。テスト自動化というと実行の自動化ばかりが注目されるようだが、実際にはassertで結果確認したり、テストデータの準備したりするほうが手間がかかるし重要だ。CIをまわすにはさらにテストケース間の依存関係を粗にしてテストスイートとして実行できるようにする必要がある。

で、まあ一般的な受託開発だとおそらく大半が手動だろう。エンハンスがあるかわからんし自動化してもテストを繰り返す回数が少ないのでコストメリットがあわないからだ。テストのやり方としてはユースケース単位の単体テストからはじまってシナリオ単位の総合テストまで順次進めていく形になるだろう。僕がよく経験するのは、単体テストはマトリックス形式のチェックリストで、結合テスト以降はシナリオベースでExcelに書いていく方式だ。マトリックス形式のチェックリストは入出力の観点でテスト漏れが無いか確認しやすい一方で、見づらくレイアウトが崩れてメンテしづらいという問題がある。テスト仕様書が書きやすくメンテしやすいというのは重要なファクターだと思うがこういう点はあまり考えられていないような気がする。

自社製品の開発だとエンハンス計画をたてやすく、テストを繰り返す可能性が高いので自動化が検討されることもあるだろう。GUIが無いならなおさらだ。この場合でも僕ならメソッドレベルではなくユースケースレベルでの自動テストを検討する。理由はそのほうがメンテしやすいと思うからだ。メソッドレベルまで細かくしてしまうとテストと実装が結びつきやすくフラジャイルなテストになると思うからだ。

じゃあTDDはどうなんだという話もあるがそこはまとまってないというか経験値が無いのであらためて考えてみたい。--);あれは設計技法であって品質面のテストではない（結果的に品質は上がると思うが）ということかも。

モックについても触れておこう。個人的な考えでは、普通の現場ではモックは使わずになるべく本物と結合してテストするのが良いと思う。モックを使いこなすためにはテストしやすい設計である必要があるわけだ。DIコンテナを活用してnew使わないとか。まあこれはモック使わなくても同じといえば同じ。ただそんな設計を普通の現場でできるかというと疑問。テストしにくい設計でモック使うともはや何を試験してるんだかわからない。ただし手段と目的が逆転している現場ではカバレッジ上げるためにモック使うとかはあるかも。--);