我在想，一旦我“伪造”了我的实现以通过测试，直到什么时候我应该离开这个伪造的实现，而不用真正的实现来改变它。
如果 TDD 是关于红绿重构；如果我伪装成 GREEN，
我应该立即实施明显的实施吗？
或者我应该等到一个新的测试调用这个伪造的实现并失败，因为它没有按照预期的方式运行？ （在我看来，这听起来像 triangulation）
所以我的问题是：
如果没有（有意或无意的）三角测量，是否可以伪造它（'直到你成功！）测试驱动模式？
谢谢！
【问题讨论】：
标签： c# .net unit-testing tdd
您应该等待（但不会太久！）新的失败测试。在你用假的把你的测试变成绿色的那一刻，你已经完全掌握了你需要的知识：你知道你要开发什么，你知道你有一点单元测试覆盖率，你知道很容易伪造那个测试。你知道你已经伪造了它。
所以现在是找出当前假货无法通过的另一项测试的时候了。让你的酒吧重新变成红色——现在你要做出另一个决定：更多地伪造它还是让它正确？如果让假货继续下去更容易，那就再假货一些并进行迭代。但如果它更容易，最后，编写你知道你需要的代码：编写它。您将安全地编写它，只需足够的测试覆盖率就可以感觉良好。完美！
【讨论】：
在工作中一直在讨论类似的事情。我的观点是，单元测试只是测试一个小单元，其中它的依赖项是模拟或存根，以便您可以插入一些给定的内容以维护您的期望。
当然，这会导致我什么时候真正实现我的接口，更重要的是我如何知道这该死的东西是有效的。这就是集成测试或 BDD 测试的用武之地。当我开始编写特定功能或故事时，我会尝试充实流经系统的 BDD 测试，这些测试应该使用所有实际实现，直至任何外部边界。我尝试在测试中使用与实际应用程序中相同的 IoC 线。一旦这个测试被充实并且是红色的，你就可以开始深入到你的单元测试并将事情连接在一起。完成后，您的 BDD 测试应该会通过。
BDD 测试的好处是您可以更改内部组件的某些部分，但只要您不更改您的要求，测试基本上保持不变。
我一直在使用 StoryQ 进行 BDD 测试，发现它易于使用。
【讨论】：