我已经听说过几年的测试驱动开发了,直到最近我开始对.NET MVC更感兴趣时,我从未真正从实际层面过度关注它.我一直在玩MVC Storefront Sample,我意识到测试驱动方法有多酷和有用.但是,我一直在使用"最后测试"方法进行编程很长一段时间,而且当涉及到业务时,我总能用我最熟悉的方法来最好地估计我的努力.
我猜测学习如何使用测试驱动的方法不像学习另一种编程语言,而是更多地改变你如何设置框架,并规划构建应用程序的要求.我不认为我可以拿起一本书并为我的一个客户使用TDD开始一个项目,我猜我的介绍需要更有条理.
对我来说,改变计划构建应用程序的思维方式的最佳方法是什么,这样我才能在最短的时间内实现测试驱动的开发？
S.L*_*ott 15
你仍然可以测试最后.没关系.我们原谅你.
了解单元测试工具如何以您当前的语言运行.
开始编写单元测试,无论你现在正在做什么.
最终,你可以转向代码 - 一点点测试 - 一点点.然后测试一点点代码.
纯测试驱动开发是理想的.实际上,大多数人都会测试一点点代码.更像是测试转向或测试引导,而不是测试驱动.
现在开始.测试你手边的任何东西.
学习 TDD 的最佳方式就是继续去做。这是迄今为止我设法让同事“被测试感染”的唯一方法——至少现在你已经充分认识到了这样做的好处。
但从更实际的角度来看，我认为您已经强调了其中一个关键想法 - 这是规划构建应用程序的要求的变化。无论你当前使用什么方法，如果你看到“需求”这样的词，你可以在脑海中想到“测试用例”，并且至少有先编写测试用例的意图。但正如其他答案所表明的那样，TDD 并不是一个全有或全无的决定。您编写的任何测试，无论何时编写，无论是之前还是之后，都是有帮助的。同样，不要认为您可以达到预先编写所有测试的状态 - 这是一个循环。
我最喜欢的是JUnit FAQ 中此项末尾的伪代码。测试用例的思维框架是一个无限循环。跳到任何地方，你编写的任何测试都会有帮助，你不会后悔的。