上手なテスト駆動開発の進め方について

まずは質問の回答から…

始めからテストをかけない

テストと実際のコードは同時に作成して、同時に育てるが正解だと思ってます。

結合テストからするべき？

単体テスト以下です。
私がやった限り、TDDのテスト用コードは常に更新しまくりです。
ロジック修正したい、テスト用コードも一緒に変えよう…は日常茶飯事です。
ドキュメントをロジックの実装と同時平行で作るのと同じような感じになります。

以下解説

TDDを初めて半年弱のクソザコナメクジです。
ようやく最近自分なりの型や成功事例ができてきて楽しくなってきました。
この体験から、自分の文章で書いてみました。

普段デバッグはどんな感じでされてますか？
私はもっぱらNode.jsなのでconsole.logですが、
質問者さんはRubyなので、開発中やデバッグ中はprintをあっちこっちに仕込んでるんじゃないかと思います。

TDDではそんなダサいことしません。

デバッグ用のprint文はあとで消すので二度手間になります。
でも、テストコードは消す必要がありません。
TDDに慣れれば消す必要がない大量のprint文に守られながら開発する仕組みが構築できます。

テストに慣れない内は大きなブラックボックスを作ってしまい、デバッグ用コードのお世話になるかと思いますが、
デバッグコードが書けないと分かれば工夫してホワイトになるように頑張るしかなくなります。
私も最近はTDDのやり方に少し慣れ、デバッグ用コードを埋め込む事が減ってきました。

さて、ココからが本題です。

ですが最初に書いたコードでは、綺麗にメソッド分割できておらず、ほぼベタ書き状態のものが多い気がします。

確かに最初は何が作りたいのか曖昧な状態なので、難しいかと思います。
こういうメソッドがいいかな？ああいうメソッドがいいかな？戻り値はInt/String/Hash？

こういう心変わりが常に側にあるのがプログラミングで、
より良い方法を思いつく度に、影響範囲をどう管理するのかが課題です。
TDDは常に最新のロジックを保てと、愚直な修正作業を徹底する管理思想です。

まずは非TDDから見ていきましょう。

1. このメソッドの戻り値はStringだったけど、不便だからHashに変更しよう
2. 頭で覚えている箇所や、ファイル検索して依存している箇所を書き換える
3. 全ての箇所の実装が終わる
4. 単体テストで確認しているとエラー・・・えっ、なんで？
5. 漏れてる箇所見つけたわ、横並び項目何個あったっけ・・・？
6. デバッグコードをアチラコチラに仕込んで、不具合を修正
7. デバッグコードを消し忘れてレビュー時や結合テスト時に見つかって先輩から叱られる

4〜7のコンボなんてあるあｒ・・・ねーよｗｗｗという感じですが、たまにあるんですよね。
もれなくフラグを回収してきた私としては、規模が大きいシステムや、システムの完成間近になればなるほど泣きを見る確率が上がるんじゃないかなと思ってます。

次にTDDを見ていきましょう。

1. このメソッドの戻り値はStringだったけど、不便だからHashに変更しよう
2. 変更箇所や影響範囲を元にテストコードを修正
3. テストを実行してアサートエラーの出るエラー項目を割り出す
4. 該当の項目を修正していく

わぁ、リスクが減った！まるで進○ゼミ！！…では終わらないのがTDDです。
TDDの2のコストは決して無視出来ません。
思いついた最善のロジックをソースコードに反映させる前に、テストコードから手を付けなければならない…これは今でも苦痛です。

これが原因でTDD否定派は多数居ます。
大抵4〜7のリスクを軽く見積もっていたり、TDDに夢みすぎで夢破れたりが主な理由だと思います。

TDDは単なるリスクヘッジとして同時並行でドキュメントを作る程度のものであり、
それ以上でもそれ以下でもないって感じですね。
放置しすぎると使えないゴミになるのでメンテが必要な所もドキュメントと似てますね。

上記２点のメリットを享受する為には、
テストは同時並行、もしくは先に作られている必要があります。
対象の実行用コードのクラスの最初のメソッドが完成するまでにはメンテを開始させたいですね。

最近の私はファイルを作ったタイミングで、
testディレクトリから始まる同じディレクトリ構造のファイルを作るように徹底しています。
もちろんテスト対象のファイルがディレクトリ移動する場合は、面倒でもテストファイルも移動させてます。

こんにちは。

（私は、自動テストはやってますが、テスト駆動開発をやったことはありませんのでその点は差し引いて見て下さい。）

まず、自動テストとテスト駆動開発は混乱しやすいですが、これらは別物です。
自動テストを実装することはたいへん好ましいと思います。ロジックを修正する際の安心感が段違いです。また、リファクタリングを頻繁に実施できるのでソースをきれいに保ちやすいです。
そして、ターゲットのプログラムより先に自動テストを記述するのがテスト駆動開発ですね。

以上を踏まえ、単体テストの自動化についての質問と感じました。
単体テストの自動化は行うべきかどうか？ 行うべきならそれはいつか？ですね。

結論としては、私は細かいレベルの単体テストを自動化すると設計変更時の工数が増大するので、原則避けた方が良いと思います。

テストを自動化すると、設計変更しても仕様が変化しないことを保証する場合にたいへん有効です。同じテストであれば何度でも最小の工数で実行できますから。
従って、設計変更して仕様変更が発生しないレベルでテストを自動化すると開発効率が良くなります。
逆に、細かい単位では設計変更すると仕様も一緒に変化する方が多いです。そのような部分についてテストを自動化しても工数ばかり掛かって意味はほとんどないように感じます。

もっとも重要なテストは、顧客へ約束している通りに動作していることを検証する機能テストです。その効率を上げるために有効なことはどしどしやるべきですが、逆に足を引っ張るようなことは避けた方が良いと思います。

むしろユニットテストを結合テスト前に実施した方がコードの品質を保ちやすい気がします。

ユニットテストでは、配列の個数や、メソッド名やクラス名を指定したアサーションを行うわけですから、名前の変更や渡される配列の個数が変われば、それでもうテストはエラーになります。

先に結合やってしまうと、人間が見る分にはエラーはでていないが、全然裏側で整合性がとれてなかったみたいな結果になりかねないと思われます。

テストもしょせん人が書くのが、テスト自体が間違っているとか観点が抜けていることはよくありますし、毎回テストを書くことでの恩恵を必ずしも受けられないのがデメリットかと思います。

本来であれば最初に書くはずだと思います。ですが最初に書いたコードでは、綺麗にメソッド分割できておらず、ほぼベタ書き状態のものが多い気がします。 
そこからリファクタリングをして、メソッドの分割、その後、各メソッドのテストコードを記述というのが理想的なような気がします。

最初の出だしをどうしようか迷いますよね。

最初からメソッド分割することが大事だと思います。TDDの場合、ボトムアップ的に作りたくなりますが、後で分割方法が変わると手戻りが大きいです。

私の場合、テストとのバランスを取ります。

最初の段階は、ラフスケッチのようなコードを書きます。
詳細でなく、呼び出し側でこんなクラスにこんなメソッドがあれはきれいにかけそうという当たりを付けます。このコードはラフスケッチなので、とりあえず捨てます。（これを一気に動作可能な状態にすると、妙に細かい部分があるので、TDDは無理です。）

それに沿って、コアになるモジュールの最小機能から設計します。

例えば、ストレージに文字列を登録するモジュールだったら、文字列を送ったら（実際に登録などせず）正常終了するようなテストを書きます。

あるいは、DBから文字列を取得するというコードであればどのようなキー（もしくはNull）を送っても、DBに問い合わせもせず一定の文字列を返すとかそういったテストです。

大事なのは、内部動作は気にせず、こういうインターフェイスがあったらいいなという考えで作成することです。

これができれは、そこから育てるのはそれほど難しくないと思います。コードを育てるのは手を動かす量が圧倒的に増えるのでコーディングに時間がかかのではないかという恐れがあると思います。

実際は、先ほどラフスケッチと呼んだコードを詳細まで書き上げた場合、すでに動作検証済みの部分の変更を避けるために、悪い設計をした部分のバグフィックスに大量の時間を割くことになります。

これがテストコードも育てるという考えでやった場合、検証済みのコードはテストコードが守ってくれます。変更が必要なテストコードは、テスト項目は変わりません。そのテスト項目がまったく不要になることがあるとすれば、それは初めには思いつかなかった素晴らしい設計を発見したとであり、それこそがTDDの最大の成果ではないでしょうか。

とはいえ、私も追加すべきコードが初めからわかるような単純なものに関してはTDDでは書かないこともおおいです。やはり、必要に応じてということも忘れてはならないことだと思います。