我知道有很多关于 TDD 的东西，我也在尝试学习实践。但我想知道对你的错误修复进行 TDD 是否是个好主意？
我正在考虑找到错误并缩小范围。编写单元测试以确保它现在可以通过它之前引起的任何问题。为其他可破坏的条件编写更多单元测试。最后编写单元测试来测试集成测试，因为在此之前我们没有任何单元测试，所以每当我修复错误时，我总是担心我可能会意外破坏某些东西。
谢谢。
所以 - 是的 - 非常如此。
当测试人员发现一个错误时，我通常会为它编写一个单元测试。当测试成功时，我知道该错误已修复，并且将来总会再次被覆盖。
当您的系统中有错误时，最好在 TDD 中编写一个发现错误的测试（即证明错误的红色测试）。当您必须修复错误时，测试最终应该变为绿色。如果它们足够接近，找出任何其他错误可能是个好主意。
关于调试，应该使用 TDD 来利用远离程序员的调试会话。如果您不知道某个错误在哪里，您仍然可以进行调试，但是如果您有一个具有足够粒度的回归测试套件，则更容易查明错误。
您必须记住，TDD 更多的是关于单元测试而不是集成测试。编写集成测试没有任何问题，因为它们是一种健全性检查，可确保您的应用程序或被测系统正常工作。
一本关于使用 xUnit 框架进行测试的书是xUnit Patterns 这本书，它足够通用，可以使用任何单元测试框架（即使是PerlUnit，我猜也是）一本你可以使用 xUnit 框架做的有趣技巧的食谱。
更新： Extreme Perl有一章关于 perl 中的单元测试。
简而言之，答案是肯定的。这样做的基本结构是编写一个测试用例来模拟错误并使测试用例失败。然后修复将通过测试用例的错误。
是的。当然，您在发布的 TDD 期间执行的所有测试都将添加到回归测试套件中。但是，在一个错误的情况下，那个回归套件显然不够详细。
修复错误的第一步是复制它，这就是TDD。一旦你找到了一个复制错误的测试用例，你可以根据需要扩展它（以捕捉同一类的其他明显问题），但我不倾向于做很多扩展，因为我们有特定的周转时间修复一个错误。
修复该错误后，将测试用例添加到回归套件中。我们的想法是不断向回归套件中添加测试用例，用于发布和错误修复，以提供很好的覆盖率。
在修复错误时，我总是在实际代码之前编写测试。
这样我就有了一个工作代码的期望示例——我可以只专注于使这个测试（以及所有其他测试，用于回归）通过。
是的，但要小心，如果你写的 bug 和我一样多，你很快就会有大量的测试来覆盖你写的所有 bug，然后修复。
这将意味着测试运行会变慢，并且行为意图会因错误测试而变得混乱。
您可以将这些测试在逻辑上分开或重新访问您原来的一组指定的行为检查（阅读测试），看看您是否真的涵盖了所有预期的行为。
我认为区分两者很重要。
我认为您最初会修复错误，然后回归测试将由 TDD 组成。