如果我正在开发一个概念验证应用程序，那么在编写自动化测试方面投入时间有意义吗？这是一个个人项目，我是唯一的开发商。
在这一点上，我认为自动化测试的唯一好处是：
- 如果概念被接受，那么测试已经存在
为这种类型的项目编写自动化测试的一些缺点可能是：
- 为一个对人们来说可能不值得的想法编写测试需要宝贵的时间
- 在这个层次上，最好花时间来展示你的想法
有人能为处于早期阶段的应用程序编写自动化测试提供投入时间的利弊吗
谷歌测试自动化会议的整个演讲都是关于您的问题：http://www.youtube.com/watch?v=X1jWe5rOu3g
基本上，结论是，知道你正在构建正确的东西比构建正确的事情更重要（构建正确的"它"，而不是构建正确的"它"）。最重要的是通过概念验证，并确保它有效且受欢迎。如果人们喜欢你的东西，那么他们会容忍bug；但是如果他们不喜欢你的东西，它可能没有错误，他们仍然不会喜欢它。
TDD不是真正的测试，而是设计。为你的应用程序做TDD会使它有一个更好的设计（可能），而不仅仅是根据你的感觉来做。
你的问题是：你需要一个好的设计吗？设计对维护很有帮助，大多数TDD开发人员在添加了第一个功能后就认为自己处于维护模式。
从一个更务实的角度来看：如果你是唯一的开发人员，有非常准确的规范，并在代码上工作，并且永远不会返回（也不会让其他人返回），我会说让它工作就足够了。
但是，如果你的POC有效，不要试图从中得到任何回报，只需重做即可。
- 你可以通过做一个丑陋的POC来节省时间，并得出你的想法不可行的结论
- 你可以通过做一个丑陋的POC并更好地理解你试图建模的领域来节省时间
- 试图从一个糟糕的代码库中提取几行代码是无法节省时间的
对于估计你应该在设计中投入多少精力（因为过度设计也可能是一个大问题），我最好的建议是：试着估计代码在中的有效期
参考资料：我建议你对"让它发挥作用，让它正确，让它快速"这句格言进行一些研究。你问的问题是关于前两点，但你迟早会问自己同样的问题，关于优化（第三点）
没有"正确"的答案。TDD可以使您的概念更强大、更有弹性、更容易实现，并有助于推动API的开发。这也需要时间，而彻底的改变意味着测试的改变。
然而，在现实生活中，你很少能完全抛弃"原型"代码。
答案完全取决于如果你证明了你的概念会发生什么True无论结果如何，概念验证应用程序都会被丢弃，如果PoC被证明是正确的，那么真正的应用程序会在之后编写。这些PoC显然不需要测试。但是有方式太多的"产品化PoC"。这些应用程序可能应该提前编写测试。你收到的其他答案为你的两个职位提供了坚实的支持，你只需要决定你正在构建哪种类型的PoC。