3

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?

Graham Swan
  • 4,818
  • 2
  • 30
  • 39

4 Answers4

5

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.

chisophugis
  • 789
  • 5
  • 8
  • 2
    That sounds like a great talk! Your summary is exactly the type of response I was looking for, and the fact that it comes from a notable organization provides lands it with some cred. I'll watch the talk right now. – Graham Swan Feb 19 '12 at 22:56
2

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.

  • You can save time by doing an ugly POC and come to the conclusion that your idea is not doable.
  • You can save time by doing an ugly POC and understanding much better the domain you're trying to model
  • You cannot save time by trying to get some lines of code out of an horrible codebase.

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)

systho
  • 1,161
  • 7
  • 17
  • Estimating the lifetime of your code is a good point to ponder. It sounds like the correct path to take relies to being lean and testing the market. Build an idea, see if people use it, and, if it passes the test, make it elegant following that. – Graham Swan Feb 19 '12 at 22:59
1

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.

Dave Newton
  • 158,873
  • 26
  • 254
  • 302
  • That's a solid point regarding tossing prototype code. I'm just putting feelers out there to see what the general consensus is. – Graham Swan Feb 19 '12 at 22:55
1

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.

Ross Patterson
  • 9,527
  • 33
  • 48
  • I agree with this statement as well. Building a throwaway concept does not require tests, but if you're going to build on top of that concept should it succeed, then tests are a must. Good point. – Graham Swan Feb 20 '12 at 16:54