我们开始的一个新项目引入了很多我们不太熟悉的新技术，以及我们没有太多实践的架构。换句话说，服务类之间的接口(interface)和交互等我们正在构建的东西是相当不稳定的，由于内部和客户的反馈，更是如此。尽管我一直对不断变化的规范感到沮丧，但我认为这在某种程度上是构建我们以前从未构建过的东西的必要部分——如果我们只坚持最初的设计和范围，最终产品可能是与现在相比，它的创新性和实用性要差很多。
我还介绍了测试驱动开发 (TDD)，因为它的好处有据可查，而且在概念上我喜欢这个想法。还有两个新东西要学习 - NUnit 和 mocking - 但看到所有这些绿色圆圈，一切都值得了。
然而，随着时间的推移，那些不断变化的设计似乎意味着我花在更改测试上的时间比花在编写代码本身上的时间要多得多。仅出于这个原因，我又回到了旧的测试方式 - 即非自动化测试。
虽然我坚信通过数百个出色的单元测试该应用程序会更加健壮，但我发现发布产品的时间权衡几乎是 Not Acceptable 。那么我的问题是 - 如果您正在制作某些东西的原型(prototype)/构建测试版，你们是否也发现 TDD 会很麻烦？ TDD 是否更自然地与规范更固定的事物或开发人员在语言和技术方面拥有更多经验的事物相结合？还是我做错了根本性的事情？
请注意，我并不是要在这里批评 TDD - 只是我不确定它是否总是最适合所有情况。
最佳答案
简短的回答是 TDD 对于 beta 版本非常有值(value)，但可能对于原型(prototype)设计的值(value)较小。
我认为区分测试版和原型(prototype)制作非常重要。
beta 版本本质上是一个仍在开发中的生产版本，因此您绝对应该在这种情况下使用 TDD。
原型(prototype)/概念验证是您构建的明确意图，一旦您从中得到想要的答案就将其丢弃。
的确，项目经理会倾向于插入将原型(prototype)用作生产代码的基础，但抵制这种做法非常重要。如果您知道那是不可能的，请像对待生产代码一样对待原型(prototype)代码，因为您知道它将来会成为您的生产代码——这意味着您应该将 TDD 与它一起使用好吧。
当您学习新技术时，大多数代码示例等在编写时都没有考虑单元测试，因此很难将新技术转化为单元测试思维方式。绝对感觉开销很大。
然而，根据我的经验，单元测试通常确实会迫使您突破所学新技术的界限。很多时候，您需要研究和学习新技术提供的所有不同钩子(Hook)，因为您需要能够通过 DI 等方式隔离技术。
单元测试并非只是循规蹈矩，而是经常迫使您更深入地学习技术，所以看起来像是开销的东西实际上只是一个更深入的原型(prototype)——一个通常更有值(value)的原型(prototype)，因为它涵盖更多领域。
就我个人而言，我认为对新技术进行单元测试是一种很好的学习工具。
我认为，您在测试可维护性方面似乎遇到的症状有点正交。您的测试可能过度指定，这在使用已知技术时也可能发生(但我认为当您更容易陷入这个陷阱时同时学习新技术)。
本书xUnit Test Patterns描述了过度指定的测试反模式，并提供了许多可以帮助您编写更易于维护的测试的指导和模式。
关于unit-testing - 在测试版/原型(prototype)制作期间进行单元测试是个坏主意吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1271716/