如果我正在开发概念验证应用程序，那么投入时间编写自动化测试是否有意义？这是一个个人项目，我是唯一的开发人员。
我认为此时自动化测试的唯一好处是：
与为此类项目编写自动化测试相关的一些缺点可能是：
- 为一个可能对人们来说不值得的想法编写测试需要花费宝贵的时间。
- 在这个级别上，最好花时间来展示你的想法。
任何人都可以提供在应用程序的早期阶段投入时间编写自动化测试的优点和缺点吗？
If I'm developing a proof-of-concept application, does it make sense to invest time in writing automated tests? This is for a personal project where I am the sole developer.
I see the only benefit of automated testing at this point as:
- If the concept catches, the tests already exist.
Some of the cons related to writing automated tests for this type of project could be:
- It takes valuable time to write tests for an idea that might not be worthwhile to people.
- At this level, time is better spent building a demonstration of your idea.
Can anyone provide pros and cons of investing time in writing automated tests for an application in its early stages?
发布评论
评论（4）
Google 测试自动化会议的整个演讲都是关于您的问题：
http://www.youtube.com/watch?v=X1jWe5rOu3g
基本上，结论更重要的是，知道你正在构建正确的东西比构建正确的东西更重要（构建正确的“它”，而不是正确地构建“它”）。最重要的是通过概念验证并确保它有效且受到喜爱。如果人们喜欢你的东西，那么他们就会容忍错误；但如果他们不喜欢你的东西，即使它没有错误，他们仍然不会喜欢它。
This whole talk from the Google Testing Automation Conference is about your question:
http://www.youtube.com/watch?v=X1jWe5rOu3g
Basically, the conclusion is that it is more important to know you are building the right thing than to build something right (build the right "it", rather than build "it" right). The most important thing is to get a proof-of-concept through and make sure that it works and is liked. If people like your thing, then they will tolerate bugs; but if they don't like your thing, it can have no bugs and they still won't like it.
TDD 并不是真正的测试，而是设计。为你的应用程序进行 TDD 将会使其拥有比仅仅凭感觉做更好的设计（可能）。
你的问题是：你需要一个好的设计吗？设计有助于维护，大多数进行 TDD 的开发人员在添加第一个功能后就认为自己处于维护模式。
从更务实的角度来看：如果您是唯一的开发人员，拥有非常准确的规格并处理此代码来完成它并且永远不会返回它（也不会发送其他人返回它），我会说让它工作就足够了。
但是，如果 POC 有效，就不要试图从中获取任何信息，只需重做即可。
对于估计您应该在设计中投入多少精力（因为过度设计也可能是一个大问题），我的最佳建议是：尝试估计该代码的生存时间
参考：我建议您对座右铭"让它工作，让它工作对，让它快点” 。您问的问题是关于前两点，但您迟早会问自己同样的关于优化的问题（第三点）
TDD is not really about testing, it's about designing. Doing TDD for your application will make it have a better design (probably) than just doing it on your feeling.
Your problem is : Do you need a good design ? Design is helpful for maintainance and most devs doing TDD consider themselves in maintainance mode just after having added their 1st feature.
On a more pragmatic perspective : if you're the only dev, have very accurate specs and work on this code to do it and never return to it (nor send someone else return to it), I would say that making it work is enough.
But then don't try to get anything back from it if your POC works, and just redo it.
My best advice for estimating how much effort you should put in design (because overdesigning can be a big problem, too) is : try to estimate how long will that code live
Reference : I would suggest you to make some research on the motto "Make it work, make it right, make it fast" . The question you ask is about the 2 first points but you will sooner or later ask yourself the same question about optimization (the third point)
没有“正确”的答案。 TDD 可以使您的概念更强大、更有弹性、更容易实现，并有助于推动 API 开发。这也需要时间，彻底的改变意味着测试的改变。
不过，在现实生活中很少会完全丢弃“原型”代码。
There's no "right" answer. TDD can make your concept stronger, more resilient, easier to bang on, and help drive API development. It also takes time, and radical changes mean test changes.
It's rare you get to completely throw away "prototype" code in real life, though.
答案完全取决于如果你证明你的概念会发生什么。 正确 无论结果如何，概念验证应用程序都会被丢弃，如果 PoC 被证明，真正的应用程序会在之后编写。这些 PoC 显然不需要测试。但市面上有太多“产品化 PoC”。这些应用程序可能应该预先编写测试。您收到的其他答案为您提供了对这两个职位的坚实支持，您只需要决定要构建哪种类型的 PoC。
The answer depends entirely on what happens if you prove your concept. True Proof-of-Concept applications are thrown away regardless of the outcome, and the real application is written afterward if the PoC proved out. Those PoCs obviously don't need tests. But there are way too many "productized PoCs" out there. Those applications probably should have tests written right up front. The other answers you've received give you solid support for both positions, you just need to decide which type of PoC you're building.