質を上げるためにテスト作るんじゃなくて、テスト作ると質を上げられる
現在携わっているプロジェクトでは、単体テストを始め、最終的な出力結果(XML)のテストなど、いろいろな粒度のテストをPHPUnitを使って書いてます。ようやく1ヶ月ちょっと経ったところで、
- 77クラスファイル(*.class.php)
- 256 Tests
- 876 Assertions
な感じで、テストはすべてパスし、コードカバレッジは95%強ぐらいをキープしてます。
で、最近思い始めたのは
質を上げるためにテスト作るんじゃなくて、 テスト作ると質を上げ*られる*
ということです。デグレードしない(しても気づきやすい)という意味で、質が「上がる」というのもあるかと思いますが。また、「テストを作りさえすれば質が上がる」みたいな印象がありますがそうではない、ということです。
今のところ、
- ざっくりクラス設計をする(クラス名とメソッドの定義とか)
- テストを書く
- 実装する
- テストを通す
- リファクタリングする(メソッドの移動とか実装の変更とか)
を繰り返し、ある一定量のテスト/実装が溜まったころにちょっと大きめの粒度(機能単位とか画面単位とか)でリファクタリングする、という流れでやってます。テスト無しの場合と実装する機能は変わらない訳ですが、今までよりも
- 最終的なコードに余計なものが残っていない
- クラスの責務が今までよりもはっきりしている
- 全体的にコードの見通しが良くなっている
という感覚が残るようになっています。
これって、「テストを書いた」からではなく、リファクタリングをすることで、コードの質が良くなっているのが理由なんだろうな、と。
テストを書いてなかった頃は、修正の影響範囲とかを気にして大幅に書き換えることを躊躇してましたが、「テスト書いておくことで、安心してコードをいじり倒せる」というのがかなり新鮮で快感です。気になるところをガンガン直していけます。
「テスト有りき」ではなく「積極的にリファクタリングしてコードの質を上げるには、オリジナルと動作が変わっていないことを保証する必要があり、それをするためにテストを書く」と考える方が腑に落ちます。
確かに、テストを書く必要があるので全体のコード量は増えますし、仕様を変えたときはテストも変更する必要がありますので手間も増えます。
が、今のところ、それらを上回る
絶対的な安心感
を感じてます。その安心感に支えられつつ、少しずつコードや品質に「保証」をかけている感覚です。そのお陰で、結構ポジティブ(当社比)に開発できてる気がします。
ということで、最近のはてダ更新/情報収集が滞り気味です。。。
やはり、もっと早く(前々職ぐらい)から本格的にやるべきだったなぁ、と後悔。
テストいいですよ、テスト。
って、id:kunitさんのようなエントリ。。。;-)