我还介绍了测试驱动开发(TDD),因为它的好处已经有了很好的记录,从概念上讲我喜欢这个想法.还有两个要学习的新东西–NUnit和嘲弄 – 但是看到所有那些绿色圆圈使得这一切都值得.
然而,随着时间的推移,那些不断变化的设计似乎意味着我花了很多时间来改变我的测试,而不是编写代码本身.仅仅因为这个原因,我已经回到了旧的测试方式 – 也就是说,不是自动化的.
虽然我毫不怀疑这个应用程序在数百个优秀的单元测试中会更加强大,但我发现推出该产品的时间权衡是不可接受的.我的问题是,那么 – 你们中是否有人发现如果你正在构建一个测试版的东西/建立测试版,那么TDD可能会很麻烦？ TDD是否更加自然地与规范更加固定的东西,或者开发人员在语言和技术方面拥有更多经验的东西相提并论？或者我做过一些根本错误的事情？
请注意,我并不是想在这里批评TDD – 只是我不确定它总是最适合所有情况.
我认为区分beta版本和原型设计非常重要.
测试版本质上是一个刚刚开发的生产版本,因此在这种情况下你绝对应该使用TDD.
一个原型/概念验证是你建立的东西,明确的意图是,一旦你得到你想要的答案就扔掉它.
确实,项目经理倾向于推动将原型用作生产代码的基础,但是抵制这种原型非常重要.如果你知道那是不可能的,那就像处理你的生产代码那样处理原型代码,因为你知道它将来会成为你的生产代码 – 这意味着你也应该使用TDD.
当您学习新技术时,大多数代码示例等都不会考虑单元测试,因此将新技术转换为单元测试思维可能很困难.它绝对感觉像很多开销.
然而,根据我的经验,单元测试通常会迫使您突破您正在学习的新技术的界限.通常,您需要研究和学习新技术提供的所有不同的钩子,因为您需要能够通过DI等来隔离技术.
单元测试经常迫使您更深入地学习技术,而不仅仅是遵循常规路径,因此可能感觉开销实际上只是一个更深入的原型 – 通常更有价值,因为它涵盖了更多的基础.
就个人而言,我认为单元测试新技术是一个很好的学习工具.
我认为,您似乎遇到的关于测试可维护性的症状有点正交.您的测试可能是Overspecified,这在使用已知技术时也会发生(但我认为当您同时学习新技术时,可能更容易陷入此陷阱).
本书xUnit Test Patterns描述了Overspecified Test反模式,并提供了许多指导和模式,可以帮助您编写更易于维护的测试.
