TDDにはたくさんのものがあることを知っています。私も練習を受けようとしています。 しかし、あなたのバグ修正をTDDするのもいい考えですか？
私はバグを見つけるの行に沿って考えていた狭めてください。 これまでに発生した問題をすべて確実に通過するように、単体テストを書いてください。 他の破壊可能な状態の単位テストを書く。 そして最後にユニットテストを書いて統合テストをテストします。これに先立ってユニットテストはありませんので、いつでもバグを修正するときにいつでも何かを壊すかもしれないと心配しています。
- TDDもデバッグに適しています あまりにも？
- または そこに他の方法やリソース/本 これはもっと役に立つでしょう 目的？
- 私はもっと心配しています。 統合テストパート 上記の通り。を探しています LAMP / Axkit / Perl関連のもの 方法。
ありがとう。
回答：
回答№1は28- テストは失敗しました。 不具合。
- コード内のバグを修正してください。
- テストを再実行します。
- すべてのテストを再実行します。
そう - そう - 非常にそうです。
回答№2のための7
テスターがバグを見つけたら、私は通常それの単体テストを書く。テストが成功すると、バグは修正されており、今後もいつも再びカバーされることがわかります。
回答№3の6
あなたのシステムにバグがあるとき、それは良いですバグを発見するテストを書く（つまり、バグを証明する赤いテスト）。バグを修正する必要があるときは、テストは最終的に緑色に変わります。彼らが十分に近づいたら他のバグを見つけ出すことは良い考えです。
デバッグに関しては、TDDを使用してデバッガセッションをプログラマから遠ざけてください。あるバグがどこにないか分からなければ、デバッグすることはできますが、十分な粒度の回帰テストスイートがあれば、バグを突き止めるほうが簡単です。
あなたは、TDDが 単体テスト 統合テストに関するものではありません。統合テストの作成には何も問題はありません。なぜなら、統合テストは、アプリケーションまたはテスト中のシステムが確実に機能することを確認するためのものです。
xUnitフレームワークでテストしている本の1つは、 xUnitパターンブック これは一般的な単位テストフレームワークで動作するのに十分です（ PerlUnit 私はxUnitフレームワークでできる面白いトリックの料理書を推測するだろう。
更新： perlでのユニットテストに関する章があります。 極端なPerl.
答え№4の3
答えは簡単です。これを行う基本的な構造は、バグをシミュレートしてテストケースを失敗させるテストケースを作成することです。テストケースに合格するバグを修正します。
回答№5の2
はい。 もちろん、リリースのTDD中に実行したすべてのテストは、回帰テストスイートに追加されます。しかし、バグの場合、そのリグレッションスイートは明らかに十分詳細ではありませんでした。
バグ修正の最初のステップは、それを複製することです。 は TDD。 バグを再現するテストケースを見つけたら、（同じクラスの他の明白な問題を捕まえるために）望みならば拡張することができますが、私たちは特定のターンアラウンドタイムを持っているので、単一のバグを修正しました。
そのバグを修正したら、テストを追加しますケースを回帰スイートに変換します。このアイデアは、リリースとバグ修正の両方についてテストケースを回帰スイートに追加し続けることで、非常に優れたカバレッジを提供します。
答え№6の場合は1
私はいつもバグを修正しながら実際のコードの前にテストを書きました。
このようにして、私は作業コードから何を期待するかの例を得ました - そして、私はこのテスト（と回帰のための他のすべてのテスト）を合格させることに集中できます。
回答№7の場合は1
はい、しかし注意してください。もしあなたが多くのバグを書いたら、すぐにあなたが書いて、修正したすべてのバグをカバーするための膨大なテストを受けるでしょう。
これは、テストの実行が遅くなることを意味し、動作の意図は、あなたのバグテストによってmuddiedになります。
これらのテストを論理的に分離しておくか、元の 指定された動作チェック （テストを読んで）あなたが本当にあなたの期待される行動をすべてカバーしているかどうかを確認してください。
私はその2つを区別することが重要だと思います。
回答№8の場合は0
最初にバグを修正してから、回帰テストをTDDで構成すると思います。