Three myths about testing
Myth 1: I don’t have time to test!
This is an often heard excuse when someone doesn’t want to write tests. Sure, it needs some additional time to write tests, but if you really want to write tests I am sure you will find the necessary time.
Myth 2: The customer doesn’t pay for testing!
That’s often true. At least if you say something like “I will need 40 hours for testing” to your customer. I think the best approach is to not mention “testing” as a separate topic and to treat tests and production code as a unit. So if you have to estimate the effort for a feature, you sum up the estimations for the production code and the tests, and present the result to the customer. If the customer accepts your offer, he will automatically pay for your testing efforts!
Myth 3: Testing slows me down!
At first sight this seems to be true as you have to write much more code, which means less production code per time unit. But in the long run you will notice that it pays off: you need less time to debug your code, it is easier to refactor your code, and you have to write less documentation as the tests document what your code does and how it should be used.
Yeah, it’s true. But soooo boring though…
@KesheR: Why do you think testing is boring?
I think there’s yet another myth - I’m writing a webapp, why do I bother with coding tests instead of just hitting reload on the browser?
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.
> I think the best approach is to not mention “testing” as a separate topic and to treat tests and production code as a unit.
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 ;)
Not to be argumentative, but.. how do you know it will pay off in the long run?
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 think we all agree that testing is important and has it’s place, but I’m not sure everyone knows how to write tests or how to incorporate them into their projects.
@All: Thanks for your comments.
@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.