我已经听说过几年的测试驱动开发,而从最近开始对.NET MVC更感兴趣的时候,我从来没有真正从实际的角度重视这一点.我已经在
MVC Storefront Sample玩了很多,而且我正在意识到测试驱动的方法可以有多么酷和有用.然而,我已经使用“测试最后”方法进行编程了很长一段时间,当它归结于业务时,我总是可以用最熟悉的方法最好地估计我的努力.
我猜测学习如何使用测试驱动的方法不像学习另一种编程语言,而是更多地改变了如何处理构建框架并规划构建应用程序的要求.我不认为我可以拿起一本书,并为我的客户使用TDD开始一个项目,我猜我的介绍需要更有条理.
什么是我最好的方式,转移我的思维方式来建立一个应用程序,所以我可以在最短的时间内测试驱动的开发生效？
接收TDD的最佳方法是继续执行.这是迄今为止我已经设法让同事“测试感染”的唯一方法 – 至少现在你对前期的好处有很好的认识.
从更实际的角度来看,我认为你已经突出了一个关键的想法 – 这是规划构建应用程序的要求的一个变化.无论您目前使用哪种方法,如果您看到“要求”这样的词,您可以精神上考虑“测试用例”,至少有意首先写测试用例.但就像其他答案所表明的那样,TDD并不是一个全然或没有决定.任何您写的测试,无论何时写入,之前或之后,都是有帮助的.同样,不要以为你可以去一个你之前编写所有测试的状态 – 这是一个循环.
我的最爱是this item in the JUnit FAQ年底的伪代码.测试用例的心灵框架是一个无限循环.跳到任何地方,你写的任何测试都会有所帮助,你不会后悔的.
