测试驱动开发的标准过程似乎是添加测试，看到它失败，编写生产代码，查看测试通道，重构，并将其全部检查到源代码控制中。
是否有任何内容可以让您查看测试代码的修订版x和生产代码的修订版x-1，并看到您在修订版x中编写的测试失败了？ （我会对任何语言和源代码控制系统感兴趣，但我使用ruby和git）
在某些情况下，您可能会添加已经通过的测试，但它们会比开发更多验证。
答案 0 :(得分：1)
有几件事：
在TDD中，添加通过的测试没有任何意义。这是浪费时间。我一直试图这样做以增加代码覆盖率，但该代码应该已经被首先实际失败的测试所覆盖。
如果测试没有先失败，那么您不知道您添加的代码是否修复了问题，而您不知道测试是否实际测试了任何内容。它不再是测试 - 只是一些代码可能会或可能不会测试任何东西。
答案 1 :(得分：1)
只需将测试和代码保存在单独的目录中，然后就可以查看一个版本的测试和另一个代码。
话虽如此，在多开发人员环境中，您通常不希望检查测试失败的代码。
我还会质疑这样做的动机？如果要首先“强制执行”失败的测试，那么我会指向TDD（推广）之父的this comment。
答案 2 :(得分：1)
“在某些情况下，您可能会添加已经通过的测试，但它们会比开发更加验证。”
在TDD中，您总是在通过之前观看测试失败，以便您知道它有效。
正如您所发现的，有时您希望明确描述您已经编写过的代码所涵盖的行为，但是当从外部考虑被测试的类时，该类是该类的一个单独功能。在那种情况下，测试将通过。
但是，仍然看着测试失败。
使用明显失败的断言编写测试，然后修复断言以使其通过。或者，暂时中断代码并观察所有受影响的测试失败，包括新测试。然后修复代码以使其再次运行。
答案 3 :(得分：0)
如果将生产和测试代码保存在单独的版本控制区域（例如，单独的项目/源树/库/等），大多数版本控制系统都允许您签出以前版本的代码并重建它们。在您的情况下，您可以签出生产代码的x-1版本，重建它，然后针对新构建/部署的可部署生产运行测试代码。
可能有用的一件事是在发布时标记/标记所有代码，以便您可以轻松地为以前版本的代码获取整个源代码树。
答案 4 :(得分：0)
有什么东西可以让你这么做 查看测试代码的修订版x， 和修订版x-1的制作 代码，看看你的测试 写在修订版x失败？
我认为您正在寻找关键字持续集成。实际上有许多工具实现为版本控制系统中的提交后挂钩（也就是每次提交后在服务器/中央存储库上运行的东西）：例如，它们将在每次提交后运行单元测试，并通过电子邮件发送提交者修订版引入了回归。
这些工具完全能够检测哪些测试 new 并且从未从过去传递的旧测试中传递，并且由于最近的提交而导致当前失败，这意味着使用TDD和持续集成完全没问题：您可能能够配置您的工具，以便在引入新的失败测试时不要尖叫，并且仅对回归进行投诉。
与往常一样，我会指导您访问维基百科generic introduction on the topic。更详细，非常着名的资源将来自Martin Fowler
的文章答案 5 :(得分：0)
如果你在编写失败的测试之后git commit，然后在他们通过时再次，你应该在以后能够在测试失败时创建一个分支。
然后，您可以添加更多测试，验证它们是否也失败，git commit，git merge，然后使用当前代码库运行测试，看看您已经完成的工作是否会导致测试通过或者如果你现在需要做更多的工作。