tdd - 如何将您的范式转变为测试驱动的开发

Question

几年来我一直听说测试驱动开发，但直到最近我开始对 .NET MVC 更感兴趣时，我才真正从实践层面对它给予太多关注。我一直在玩 MVC Storefront Sample ，并且我意识到测试驱动方法可以是多么酷和有帮助。但是，我已经使用“最后测试”方法编程很长时间了，当涉及到业务时，我总是可以用我最熟悉的方法最好地估计我的工作量。

我猜想学习如何使用测试驱动方法不像学习另一种编程语言，而是更多地改变了您如何为构建应用程序构建框架和规划需求的方法。我不认为我可以拿起一本书并使用 TDD 为我的一个客户启动一个项目，我猜我对它的介绍需要更有条理。

改变我的计划思维方式来构建应用程序以便我可以在最短的时间内有效地进行测试驱动开发的最佳方法是什么？

Answer 1

接受 TDD 的最好方法是继续做下去。到目前为止，这是我设法让同事“测试感染”的唯一方法——至少现在你已经很好地了解了这些好处。

不过，从更实际的角度来看，我认为您已经强调了其中一个关键思想 - 改变构建应用程序的需求。无论你目前使用什么方法，如果你看到像“需求”这样的词，你都会在心里想到“测试用例”，至少有先写测试用例的意图。但就像其他答案所暗示的那样，TDD 不是一个全有或全无的决定。您编写的任何测试，无论何时，无论是在之前还是之后，都是有帮助的。同样，不要认为您可以达到预先编写所有测试的状态 - 这是一个循环。

我最喜欢的是 this item in the JUnit FAQ 末尾的伪代码.测试用例的思维框架是一个无限循环。跳到任何地方，您编写的任何测试都会有所帮助，您不会后悔。