まずは質問の回答から…
始めからテストをかけない
テストと実際のコードは同時に作成して、同時に育てるが正解だと思ってます。
結合テストからするべき?
単体テスト以下です。
私がやった限り、TDDのテスト用コードは常に更新しまくりです。
ロジック修正したい、テスト用コードも一緒に変えよう…は日常茶飯事です。
ドキュメントをロジックの実装と同時平行で作るのと同じような感じになります。
以下解説
TDDを初めて半年弱のクソザコナメクジです。
ようやく最近自分なりの型や成功事例ができてきて楽しくなってきました。
この体験から、自分の文章で書いてみました。
普段デバッグはどんな感じでされてますか?
私はもっぱらNode.jsなのでconsole.logですが、
質問者さんはRubyなので、開発中やデバッグ中はprintをあっちこっちに仕込んでるんじゃないかと思います。
TDDではそんなダサいことしません。
デバッグ用のprint文はあとで消すので二度手間になります。
でも、テストコードは消す必要がありません。
TDDに慣れれば消す必要がない大量のprint文に守られながら開発する仕組みが構築できます。
テストに慣れない内は大きなブラックボックスを作ってしまい、デバッグ用コードのお世話になるかと思いますが、
デバッグコードが書けないと分かれば工夫してホワイトになるように頑張るしかなくなります。
私も最近はTDDのやり方に少し慣れ、デバッグ用コードを埋め込む事が減ってきました。
さて、ココからが本題です。
ですが最初に書いたコードでは、綺麗にメソッド分割できておらず、ほぼベタ書き状態のものが多い気がします。
確かに最初は何が作りたいのか曖昧な状態なので、難しいかと思います。
こういうメソッドがいいかな?ああいうメソッドがいいかな?戻り値はInt/String/Hash?
こういう心変わりが常に側にあるのがプログラミングで、
より良い方法を思いつく度に、影響範囲をどう管理するのかが課題です。
TDDは常に最新のロジックを保てと、愚直な修正作業を徹底する管理思想です。
まずは非TDDから見ていきましょう。
- このメソッドの戻り値はStringだったけど、不便だからHashに変更しよう
- 頭で覚えている箇所や、ファイル検索して依存している箇所を書き換える
- 全ての箇所の実装が終わる
- 単体テストで確認しているとエラー・・・えっ、なんで?
- 漏れてる箇所見つけたわ、横並び項目何個あったっけ・・・?
- デバッグコードをアチラコチラに仕込んで、不具合を修正
- デバッグコードを消し忘れてレビュー時や結合テスト時に見つかって先輩から叱られる
4〜7のコンボなんてあるあr・・・ねーよwwwという感じですが、たまにあるんですよね。
もれなくフラグを回収してきた私としては、規模が大きいシステムや、システムの完成間近になればなるほど泣きを見る確率が上がるんじゃないかなと思ってます。
次にTDDを見ていきましょう。
- このメソッドの戻り値はStringだったけど、不便だからHashに変更しよう
- 変更箇所や影響範囲を元にテストコードを修正
- テストを実行してアサートエラーの出るエラー項目を割り出す
- 該当の項目を修正していく
わぁ、リスクが減った!まるで進○ゼミ!!…では終わらないのがTDDです。
TDDの2のコストは決して無視出来ません。
思いついた最善のロジックをソースコードに反映させる前に、テストコードから手を付けなければならない…これは今でも苦痛です。
これが原因でTDD否定派は多数居ます。
大抵4〜7のリスクを軽く見積もっていたり、TDDに夢みすぎで夢破れたりが主な理由だと思います。
TDDは単なるリスクヘッジとして同時並行でドキュメントを作る程度のものであり、
それ以上でもそれ以下でもないって感じですね。
放置しすぎると使えないゴミになるのでメンテが必要な所もドキュメントと似てますね。
上記2点のメリットを享受する為には、
テストは同時並行、もしくは先に作られている必要があります。
対象の実行用コードのクラスの最初のメソッドが完成するまでにはメンテを開始させたいですね。
最近の私はファイルを作ったタイミングで、
testディレクトリから始まる同じディレクトリ構造のファイルを作るように徹底しています。
もちろんテスト対象のファイルがディレクトリ移動する場合は、面倒でもテストファイルも移動させてます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/02/06 12:33
退会済みユーザー
2017/02/06 14:22
2017/02/14 03:52
2017/02/14 04:48 編集
2017/02/14 09:10 編集
2017/02/24 02:50