版本控制和测试驱动开发 [英] Version control and test-driven development

问题描述

测试驱动开发的标准流程似乎是添加测试、查看失败、编写生产代码、查看测试通过、重构并将其全部检查到源代码控制中.

The standard process for test-driven development seems to be to add a test, see it fail, write production code, see the test pass, refactor, and check it all into source control.

是否有任何东西可以让您检查测试代码的修订版 x 和生产代码的修订版 x-1，并查看您在修订版 x 中编写的测试是否失败?(我对任何语言和源代码控制系统都感兴趣，但我使用 ruby​​ 和 git)

Is there anything that allows you to check out revision x of the test code, and revision x-1 of the production code, and see that the tests you've written in revision x fail? (I'd be interested in any language and source control system, but I use ruby and git)

在某些情况下，您可能会添加已经通过的测试，但它们会比开发更需要验证.

There may be circumstances where you might add tests that already pass, but they'd be more verification than development.

推荐答案

在某些情况下，您可能会添加已经通过的测试，但它们比开发更需要验证."

"There may be circumstances where you might add tests that already pass, but they'd be more verification than development."

在 TDD 中，您总是在测试通过之前观察它是否失败，以便您知道它是有效的.

In TDD you always watch a test fail before making it pass so that you know it works.

正如您所发现的，有时您想明确描述您已经编写的代码所涵盖的行为，但如果从被测类的外部考虑，则是该类的一个单独功能.在这种情况下，测试将通过.

As you've found, sometimes you want to explicitly describe behaviour that is covered by code you've already written but when considered from outside the class under test is a separate feature of the class. In that case the test will pass.

但是，仍然看着测试失败.

But, still watch the test fail.

要么使用明显失败的断言编写测试，然后修复断言以使其通过.或者，暂时破坏代码并观察所有受影响的测试失败，包括新的测试.然后修复代码使其再次工作.

Either write the test with an obviously failing assertion and then fix the assertion to make it pass. Or, temporarily break the code and watch all affected tests fail, including the new one. And then fix the code to make it work again.

这篇关于版本控制和测试驱动开发的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！