テストを書くタイミング

「テストは時間がないから後で」

こんな言葉を聞くことは最近は減ったかもしれません。しかし今もテストは往々にして後回しにされる、そもそも書かれない、などといったことがやはり多くあるように感じます。言い換えればアプリケーションコードと比べて明らかに軽視されがちです。そんな後回しにされがちなテストコードにも書かれるのに適したタイミングというものがあります。

これから書くのはすべて私の個人的な考えになるので、必ずこれが正しいとは思わないでください。

テストを書くのに適したタイミング

結論からいうと、直前 か 直後 です。ついでに一緒に言ってしまいますが、テストを書くのに適した人間は 実装者本人 です。殆どの場合はこれが適したタイミングと人間になると思います。

直前

おそらく最も適していると思うタイミングがここです。「なんだ、TDDしろって言いたいのか」と思ったかもしれませんが、そういうことではありません。ついでに説明しておくと実装の前にテストを書くことがTDDというわけではないということだけ言っておきます。

あるメソッドや機能を作る場合に当然ですがまず存在するのはコードではありません。目的 です。後に説明しますが、この目的に近いほど適していると考えています

直後

次に適していると思うのが実装直後です。もう少し具体的に言うならば、目的に沿ったコードを書いた直後です。

なぜ直前、直後なのか

実装後、例えば１週間後にテストコードを書くとしましょう。その開発者はその１週間の間に同じプロジェクトの別メソッドのコード、別プロジェクトのコードなどを当然書くでしょう。そして１週間前に実装した自分のコードのテストを書くとします。そのときに開発者はそのメソッドを実装した目的を正しく覚えているでしょうか？そんなことを覚えていなくてもコードを見ればテストは書けると思うかもしれません。そこで１つ大げさかもしれない例をあげてみます。あるメソッドがありそのメソッドが下の図のような状態になっているとします。

目的と実装がずれていますね。このコードはおそらくバグを引き起こすでしょう。ここで、テストコードを追加することにします。この実装のコードを見て書いたテストは「a,bの積を返す」ことをテストするテストコードになるでしょう。つまり、目的とは違ったテストをパスするテストを追加することになります。これほど単純な例だと実感がわかないかもしれませんが、１週間のうちに無数のコードを見て、書いた結果、１週間前のコードが何をしているかはわかるが、なんのために存在するかはわからなくなってしまうものです。 今回の例でいうと、「a,bの積を返しているメソッド」ことはわかるが「a,bの和を返すためのメソッド」であることは忘れてしまっているという状態です。これが１週間ならまだいいですが、１ヶ月後、２ヶ月後になると最悪で、なにをしているかすらわからなくなってしまいます。こうならないうちにテストを書くのはできるだけ早いほうがいいのです。つまり直前が最も適していて、時間が経てば立つほど基本的にテストコードの質は下がっていきます。

実装者本人

もう分かると思いますが、テストコードを書くのに適した人間は多くの場合は実装者本人です。これも同じ理由で、実装者本人が目的を一番理解している人間のハズだからです。他人の書いたコードが何を目的としているかを正しく理解するのは無理ではないですが、それを理解するよりも最も理解しているであろう人間がテストコードを書いたほうが効率的です。

おわり

思ったことを書きなぐったので、拙い部分も多いと思いますが、結局言いたいのはテストはできるだけ 早く 実装者本人 が書きましょうということでした。