如果你要使用TDD,最好从一开始就使用它。
如果你相信这是正确的选择,那么就使用它,否则在将来决定使用它时可能会遇到麻烦。
当然,你肯定会重写它们,因为事情总是在变化。
如果你进行了完整彻底的需求分析,事情也会发生变化(更有可能是在你追逐那个幻想的时候已经发生了变化),你将不得不重新分析。
但是,如果你直接开始编写代码并完成一些可交付成果,你将没有任何有用的分析和测试,而整个销售部门都会摩拳擦掌,因为交付=可销售。
迭代,编写你能够编写的测试,实现它们,看看下一步该怎么做。无论是TDD还是传统的瀑布模型,在你拥有一些软件之前,都需要大量的前期工作。
把前期工作放在第二位,没有多少用处,也永远不会发生。
也许你需要更多的概念验证或故事板,或者更好的分析,但是所有的跳进去只会在仪表盘上放置虚假的笑脸,你唯一能得到的赞誉就是当车轮脱落时被踢在要害部位,以及次贷款式的技术债务危机。
是的,我认为从一开始就开始编写测试非常重要。TDD(测试驱动开发)不仅仅是测试单个类。它应该指导您在设计阶段做出的决策。
当您首先编写测试时,您将更好地了解您的问题。您说您可能会稍后重新编写它们。如果是这种情况,那么这可能意味着您将更好地了解您的系统,这是一件好事。然后,您可以通过实施进一步的测试或重构现有测试来重新设计系统。
虽然可能感觉浪费时间,但实际上并不是,因为您将更好地了解正在处理的系统。
我目前正在阅读的一本书(《Growing Object Orientated Software Guided by Tests》)提到了“Walking Skeleton”概念。它建议您使用TDD开发最小的工作解决方案,即使它非常基础。
另一个重要的观点是,您应该尝试从一开始自动化部署。这不完全是单元测试,而是部署测试,与单元测试同等重要甚至更重要。如果您在项目开始时进行此类测试,则不会在发布日期附近遇到意外问题。您还将更好地了解系统的不同组件如何配合。