_ テストコードがもたらす◯個の良いこと

タイトルは釣りです。釣れたのかわかりませんが。

昨日はTDD Boot Camp Tokyoが行われたということで、申し込みに乗り遅れて参加できなかったので、色々とテストについて考えてみた。

自分が真面目にテストコードを書くようになったのは、東京Ruby会議03の@t_wadaさんのワークショップに参加してからだ。今でもこのワークショップで得た感動を覚えている。簡単なハンズオンではあるが、テストが開発を駆動するところを実感できた。それまで、テストコードは書きたくても

• テストコードを書くということはコード量が増えて、開発期間が伸びる
• コード量が増えるので、コードレビューの量も増える

といった漠然としたリスクを感じていたので、利点を感じつつも、テスト駆動開発をやる気が起きていなかった。 ところが、先のワークショップで、利点の方が大きいし、むしろこの不安はほとんど起き得ないと感じた。そして、今では実際にその不安は無い。

テストコードを書くということはコード量が増えて、開発期間が伸びるか？

テストの分も書かなければならないので、コード量は増えるかもしれない。だが、これが単純に開発期間を伸ばすかというと、そうではない。 ある機能を開発をする時、開発者が行うことは単にコードを書くだけではなく、その前に

• 機能の仕様を理解し、
• 機能の実現方法を考える

という2つの工程があり、そして、それをコードで表現すると思う。テストコードを書くということは、これら2つの前工程に相当する。

テスト駆動開発をやり始めの頃は、この過程に時間がかかるかもしれない。自分はそうだった。けれど、これはコード量が増えたからではなく、それまで頭のなかで仕様を理解する上で使っていた言葉が、自然言語からプログラミング言語に変わったためだ。本質的な仕様理解に時間がかかるようになったのではなく、その表現方法が変わったので、新しい表現方法に慣れさえすればいい。

つまり、TDD導入直後は学習コストの分だけ増えるけど、そのリスクは継続することで抑えることができる。

コードの量が増えるので、コードレビューの量も増えるか？

レビュワーは、変更されたコード、新たに追加されたコードをレビューする。レビューする観点はチームやプロジェクトに依るのが、TDDを導入した直後はテストコードが加わった分だけ、レビュー対象のコード量は増える。

レビュワーがやることは、開発者が書いたコードやドキュメントから

• 機能の仕様を理解し、
• 機能の実現方法を考える

そして、レビューすることだと思う。テストコードはこの工程を助ける。 テストコードには、開発者が理解した仕様が、「どういう時に（前提条件）、どうなっているべき（期待値）」という形で書かれているので、理解しやすい。 しかし、以前はそれが異なる言語、つまり自然言語だったのがプログラミング言語に変わっているので、TDD導入直後は時間がかかる。

結局、開発の時間が増えるかもしれない、というのと同じことで、学習コストによって時間は一時的に増えるが、継続することで抑えることができる。

上の2つのリスクは解消可能なので、利点の方が自然と大きくなる。 ドキュメントや口頭の自然言語でやりとりしていた仕様理解を、実行可能であるプログラミング言語にすることで色々捗る。

まとまりのない文章になってしまったけど、要するにテスト駆動で開発に取り組まない理由は無いと思うので、みなさんテストを書いてハッピーエンジニアライフを送りましょう。