自動テストとデイリービルドを組み合わせることの超絶な威力を感じてる。
しかし、開発の中に上手く自動テストを組み込めていないプロジェクトは多い。
デイリーでテストコードを流しておくと、修正による副作用を最低でも1日以内に発見することができるようになる。
影響を恐れずに修正ができるため、大胆なリファクタリングも可能だし、仕様変更にとても強くなる。
結合テスト以降は、特に強力で自分の作っていないプログラムでの修正や操作が自分のプログラムに影響を与えることがある。
それを知らせてくれる仕組みがあるということが安心感は絶大だ。
そもそもテストコードを作ると、コーディング時やデバッグ時に起動ポイントとして使える。
Web画面を起動しなくていいぶん楽にコーディング・デバッグできる。
「じゃあ、Web画面からの入力テストはどうするんだ？」とか
私も昔は思っていたけど、画面入力のテストなんかは無理に自動化しなければいい。
手動テストでいいじゃないか。
テストコードの位置づけを「単体テストを代替するもの」と考えるとコスト高だけど、
テストコードは単体テストとは別物だと考えるべきだ。
最近、私が感じる自動テストの鉄則は以下だ。
- 自動テストは、手動テストとは役割が違う。
- テストコードは、網羅性を目指してはいけない。
- 手動テストは、網羅性を目指してよい。
- テストコードで見つけるのは、危険信号でよい。
- 「この変数が100をきってるのはおかしいんじゃない？」とかってこと「108であるべき」と断定する必要はない。
- バグを修正した箇所にはテストコードを書く。バグは密集するからだ。
- テストコードは成長させるものだ。
- テストコードは、繰り返して実行されることを意識して書く。
- テストコードを取りまとめる専任者が必要。
- テストコードは、1機能につき1~2つでも良い。
- 1機能につき、最低1つは「ここだけはバグってほしくない」箇所があるはずだ。そこだけにテストコードを仕込め！
- 1機能につき、最低1つは「仕様変更があるだろう」という箇所があるはずだ。そこだけにテストコードを仕込め！
上記のような、様々な鉄則がある。
一言でまとめると
自動テストは弱い部分を中心に作っておき、手動テストを補う
って感じ。
特に意識したいのが最後の2つの鉄則。
1つの機能や1つの画面について、1つはクリティカルな部分がある。
ここに、テストコードを仕込んでおくだけで周辺のコーディングが随分楽になるはずだ。
自動テストの例
例えば、僕は受注機能を作るときに、「受注番号の採番」機能だけしっかりとテストコードを埋め込んだ。
受注番号のルールは、頻繁に変更することが予見されたからだ。
他の部分は、手動アンド目視でテストする。
それで十分に威力がある。
採番ルールがいくら変わっても、テストコードがあったから余裕で対応できた。
「仕様変更になりますので、追加費用が、、、、」という、
サービス業にあるまじき苦しい交渉をしなくて済む。
当然、コーディング時やデバッグ時にはテストコードを「受注番号の採番」機能の起動コードとしてつかった。
