ユニットテストを理解し、ちょうどよく書けるようになるまでの道筋について

Question

テストを書かないコードはレガシーコードであると言われたり、テストは書かなくて良いんだという意見もあったりしますが、少なくとも書けるに超したことは無いかと思います。

RailsやFuelPHPなどの最近のフレームワークにはユニットテストを簡単に利用できるようになっていますので、マニュアルを見て使ってみたりもするのですが、どうも何となくしか理解できていません。

テストを書くのが当たり前という方は、どのような過程を経て、テストを書けるようになったのか。やはり試行錯誤しか無いのか、それともテストが書ける人にレビューしてもらったからなのか、他人の書いたテストを読んだからなのか。一度テスト駆動開発をしてみないと分からないのかなど、疑問が尽きません。

どのように学習、演習していったら良いか、皆さんの意見を聞きたいと思っています。

また、テストが「分かった」と思う瞬間が訪れるものなのか、テスト最高！と思うほど便利というか助かるものなのか、テストを書いているエンジニアの方の意見というか、エピソードというか、何かしらのテストに対する思いを聞かせて頂ければと思っています。

Answer 1

私の場合は、リファクタリングのため書いています。

リファクタリングが必要無いほど分かりきって単純なプログラムの場合、テスト
を書かないときが多いです。

逆に、どうコードに落として良いのかわからずラフスケッチのようにコードを書く
場合もテストを書きません。
これは、インターフェイスの変更にユニットテストは追随しづらいからです。
といっても、最後はテストするので書きますが。。。

大体の場合はその中間なので、テストは書きます。
構造を考えながら、クラスやメソッドなど設計して、それからテストを書きます。
出来るだけ下記の順で行いたいのですが、実装後にテスト追加することが多いです。
テスト追加→テスト→実装→テスト→リファクタリング→テスト

リファクタリングをするには、ユニットテストなしには効率が非常に悪いです。

テストの意味を知りたければ、手動で何度も同じテストをやっている気づいた
時にテストを書くことです。ユニットテストと呼ぶには大雑把なテストかもし
れませんが自動化されたテストの恩恵を感じることができます。

その次にする経験は、プログラムが複雑化してきて「０から作りなおしたい」
と思った時です。そのタイミングでは、テストの追加方法がわからないと
思いますが、ユニットテストがあれば作りなおしても機能が保証されます。

それで、新しく組むプログラムにテストを意識したコードを書いてテストを
するということを初めてすることになると思います。テストの書き方がわからず
一番苦労するかもしれません。しかし、書き終わった時にモジュール設計が
どうあるべきか理解出来ていると思います。これはユニットテストのおまけ
でこれを目的にしても良いほどの効果があります。

そうして、ある程度ユニットテストに慣れてくると、レガシーコードにテスト
を追加出来るようになります。この段階に入るとテストを書いていなかった時
の自分がどのようにコーディングしていたか思い出せなくなるほど、リファク
タリングを当たり前にするようになっています。

ユニットテストなしでも、優れたプログラミングは出来るかもしれません。
しかし、優れたプログラマになりたいのなら、ユニットテストは書くべきだと
思います。

Comments

[amaranthine]

おそらく自分の理解の程度は浅そうですが、言われていることはいちいち腑に落ちました。
作り直したいときにテストが便利というのは、作り直したときの苦労がよみがえったと同時に確かに便利かつ楽だったろうになと思いました。

一つの道筋が見えてきました。ありがとうございます。書くべきというのは理屈では分かっているのですが、感覚的に分かってきました。

Answer 2

テストは「書く」のももちろん重要ですが
まずは常にテストが走るという環境(CIとか)を用意すること
そしてプロジェクトの成長に合わせて、テストを追加修正削除し育てる過程
さらにテストを活用しての品質向上など「使う」というステージにならないと
これや！！感は無いのかもしれません。(という気がしたのです)

Comments

[amaranthine]

なるほど。CIを回してみることで分かる気がするのですね。確かに感覚的に納得行きますね。ありがとうございます。