あわあわエラーログ~わりと技術的~

yachtseaのライフログ・メモ・日記のようなもの

テストコードは先か後か

最近うちのプロジェクト回りでユニットテストに関する

気になる話題が上がったので自分も考えてみた。

 

ユニットテストは先に書くか後に書くか

 

TDDって言葉もあるんだし先に書くのが理想なんじゃね?

と漠然と思っていたけど、

かなり技術力の高い先輩が後書きだと言い続けているので、

(もちろんテストファーストだと言っている先輩も

それはそれは技術力が高いのだけれど)

もはやどちらが適しているかということではなくて

好みの問題なのかなあと思ってきている。

 

で、テストファースト派の意見としては

「 自ずと良いクラス設計になる」ということらしい。

 

これは確かにその通りで、

テストが先にあると依存性の高いコードは書き辛いので

自ずと単一責任の原則に従うことになるのだろう。

 

また、後から書く場合に比べて

mockを使用するコーディングが容易になるという意見も。

 

 片や後書き派の意見としては

「いきなり完璧なクラス設計をするのは難しい」ということらしい。

 

これも確かにその通りで、通常はリファクタリング毎に

クラス設計も含めての品質が向上するはずなので、

その中でテストを書く方が効率が良いのかもしれない。

 

どちらの意見も納得できる部分があるし

さすができる人たちは違うね。

 

それに、彼らの言葉の中には

自分が受け取れきれてない部分もあるんだろうし、 

仕様さえ満たせば何でもいいぜヒャッハー!

とか言ったら殺されそう(・・;)

 

まあ、そうは思ってないけどね。

 

で、自分はどのような方針でやっていたかなーと思い返すと

どっからどう見ても後書き派だった。

 

自分の力量だとテストファーストは確かに設計が良くなる気がするけど

テストに合わせて実装を調整して…実装に合わせてテストを調整して…

みたいになんかどっち着かずになって効率悪!ってなることが多い。

 

つまりクラス設計を詰められてない段階で

テスト書いてるってことなんだろうね。

 

やっぱり俺みたいな素人は

いきなり完璧なクラス設計をするのは難しい…あれ?

なんか後書き派の先輩の意見に寄ってる。

 

話題はちょっと変わるんだけど、

顧客の一言で仕様が揺らぐような自分たちの仕事では

完璧にテストファーストにしてしまうとリスクが高い気がする。

 

今自分にできる最善は、テストケースを想定した実装を心がけつつ

仕様が確定した(といっても覆される場合もあるけど)段階で

がっつりテストを書くことなのかもしれない。

 

…てか、その前にレガシーコードの撲滅運動からか(+_+)