@as230: I agree with you. I think it is a learning process a developer has to undergo until he sees that the “hit-reload-to-test” method is not that efficient. I for example used this method many years…

@Matthias: I think it depends on your philosophy whether you mention the testing efforts to the customer. “Software testing” is rather abstract for most customers and it is difficult to explain why testing takes as long as programming itself ;-)

@keymaster: At least for me testing is an integral part of my “production process”, as it is the way I usually work. So it doesn’t matter whether a site will change much after it has been created.

@theman: Yes, I agree with you. I wrote in earlier posts about how to write tests.

Certainly in the short run it is extra overhead that slows things down.

Doesn’t it depend on how much future development and evolution you intend to do on the product?

If you are just building a simple site for a client where you don’t think it will change much thereafter, I’m not sure it makes sense to invest the extra time setting up automated testcases.

On the other hand, if you are starting a product which you intend to have several versions/releases in the future, and build upon – it would be suicide not to setup automated testing.

It all depends on the future regression testing requirements.

I am sure this is the worst approach, not the best.
Not to mention testing efforts is like not doing it (even if you hide the costs in other features). Explain your customers why testing is important and why it will reduce cost in the long run.

As you write in myth3:

> But in the long run you will notice that it pays off

Testing means quality. And quality will pay off – as we all know ;)

Even if there’s Serenium which can test the behavior of the webapp on the browser, some people still tend to use the traditional “hit-reload-to-test” method, which cost a lot more time than writing tests to do the same.

Gotta find someway to punish those mind snatchers.