我看到很多 TDD 从业者遵循这个循环:
1) Write your test as if the target objects and API already exists.
2) Compile the solution and see it break.
3) Write just enough code to get it to compile.
4) Run the test and see if fail.
5) Write just enough code to get it to pass.
6) Run the test and see it pass
7) Refactor
第 1 步和第 2 步的优点是什么？对于像 Visual Studio 这样的 IDE，这样做真的很烦人，因为智能感知会到处乱跳，试图猜测不存在的方法和属性。
我通常从第 3 步开始，让我所有的方法都抛出 NotImplementedException，这对我来说似乎很好，但也许我遗漏了一些东西。
编辑澄清 :这不是为什么我应该在测试通过之前看到测试失败的问题；这在第 3 步开始涵盖，它完全有道理。我的问题是为什么甚至在此之前人们会在单元测试中调用 API 中不存在的方法(因此 VS 会显示红色波浪线，或将整个方法名称涂成红色等)并尝试编译。对我来说，VS 告诉我该方法不存在这一事实已经足够好了。
最佳答案
然后先写方法名试试。我发现通过首先编写测试和方法，它迫使我真正考虑 API，而且我可以轻松地更改名称而不必担心已经编写的代码。我的建议是尽量不遵守规则，并监控会发生什么。如果您发现它导致问题，请切换回来。如果没有，您现在就有了一种新的工作方式。
还要记住，当您第一次学习事物时，通常您需要一套明确的规则来为您提供上下文。当您开始从初学者转向更高级时，您将获得更多上下文并能够进行调整。在我看来，这就是你所在的地方。
关于visual-studio-2008 - 在 TDD 中，甚至在编写空方法之前运行测试有什么好处？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/417735/