自動化テストは部分的にでもいいからやる

僕はテスト駆動開発が理想だと思っていますが、しかし全てのコードが１００％テストファーストで書けるかというと、なかなかそうは行かないという現実も理解しています。それに、GUIに関わる部分など、そもそも自動化テストを書くのが困難なケースもありますよね。例えばメニュー選択の際にアニメーション効果やドラッグアンドドロップの動作確認など、間接的にステータスの値などを自動化テストで確認することはできても、直接的な確認は人間の目でやるしかなかったりします。

しかし、それでも自動化テストをやれる範囲で可能な限りやっておくことは非常に良いことだと僕は思います。テストコードはできるだけ先に書いたほうがいいですが、先に書くことができないなら後から書いてもいいです。それでもテストコードがないよりは遥かにましです。

僕が自動化テストを初めて実務で経験したのはPHPのフレームワークであるsymfonyを使ったプロジェクトを担当した時です。そもそもそれまで自動化テスト自体よく知らなかったので、symfonyに付属しているテスティングフレームワークのlimeについて調べながら行っていきました。実は最初は面倒だと思いましたし、自動化テストの恩恵をいきなり最初から実感できたわけではありませんでした。はっきり恩恵を感じたのは始めてから数ヶ月経過してからでした。

１つの仕様変更だとしても、実際はプログラムの様々んな箇所を変更しなければ整合性が保たれません。そしてその際、今まで自分が書いたプログラムがきちんと動くか全て確かめるのは手動では相当大変です。仕様の変更がかなり大胆に入るプロジェクトでしたのでなおさら毎回すべての仕様を確認手動で確認していたら非常に苦労したと思います。しかし、自動化テストのおかげで手動での確認作業を大幅に短縮できたので、開発をスムーズに進めることができました。また、自動化された部分は少なくともテストコードの書いた範囲での確認漏れは発生しないので、単純ミスによる漏れを心配せずとも済むという意味で安心して開発を進められました。

ということで、今進めているプロジェクトでも自動化テストをできるだけ広い範囲カバーする方針で進めています。前回の経験を活かしつつさらに効果的なテスト手法を取り入れていくつもりです。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。