質問: 現在RailsアプリケーションでRSpecを使いながらテスト駆動か初に挑戦しています。 幾つかテストを書いて思ったことを質問させていただきます。 (テストを導入したのはアプリケーションの機能をほとんど実装してからです) ### 始めからテストをかけない 今回は、実装がほとんど出来ている状態からテストを書いているので、テストコードをメソッドごとにかけるのですが。 本来であれば最初に書くはずだと思います。ですが最初に書いたコードでは、綺麗にメソッド分割できておらず、ほぼベタ書き状態のものが多い気がします。 そこからリファクタリングをして、メソッドの分割、その後、各メソッドのテストコードを記述というのが理想的なような気がします。 ### 結合テストからするべき?(テスト=>実装の流れならば) 単体テストの場合ではクラス単位、メソッド単位で行うことが多いかと思います。 テストコードの中でクラスやメソッドを呼び出すということは、クラス名やメソッド名の変更、引数の有無など変更できなくなります。(その都度テストコードを書き換えるのならば良いのですが) なので、結合テスト(ブラウザぽちぽちして、最終に得られる結果を期待するコードを書く)をすると、メソッドの分割や、名前の変更ができるようになるのではないでしょうか? その後単体テストを記述し、ロジックの部分をリファクタリングするというのが良いのではないかと思います。 皆様の意見を聞かせて頂きたいです。
回答: こんにちは。 (私は、自動テストはやってますが、テスト駆動開発をやったことはありませんのでその点は差し引いて見て下さい。) まず、自動テストとテスト駆動開発は混乱しやすいですが、これらは別物です。 自動テストを実装することはたいへん好ましいと思います。ロジックを修正する際の安心感が段違いです。また、リファクタリングを頻繁に実施できるのでソースをきれいに保ちやすいです。 そして、ターゲットのプログラムより先に自動テストを記述するのがテスト駆動開発ですね。 以上を踏まえ、単体テストの自動化についての質問と感じました。 単体テストの自動化は行うべきかどうか? 行うべきならそれはいつか?ですね。 結論としては、私は細かいレベルの単体テストを自動化すると設計変更時の工数が増大するので、原則避けた方が良いと思います。 テストを自動化すると、設計変更しても仕様が変化しないことを保証する場合にたいへん有効です。同じテストであれば何度でも最小の工数で実行できますから。 従って、設計変更して仕様変更が発生しないレベルでテストを自動化すると開発効率が良くなります。 逆に、細かい単位では設計変更すると仕様も一緒に変化する方が多いです。そのような部分についてテストを自動化しても工数ばかり掛かって意味はほとんどないように感じます。 もっとも重要なテストは、顧客へ約束している通りに動作していることを検証する機能テストです。その効率を上げるために有効なことはどしどしやるべきですが、逆に足を引っ張るようなことは避けた方が良いと思います。