Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I was in the 'testing is too much overhead' crowd for years until one day I finally got it. I realized that as I code, I'm always testing. Who doesn't make a change and then test it? So, you consider writing a test too much overhead? How much overhead is it to manually test? How much overhead is it to fill out that registration form you're testing? Maybe there are two or three steps to it. How much time does that take each and every time you test? Being one that enjoys automating repetitive tasks, writing that test _once_ suddenly became a no-brainer.

This realization only made all the other arguments for testing that much stronger.



True story: I took over for a developer working on a large and complex multi-step form. I wasn't surprised that there were a few little bugs in it, but I noticed that the number and severity of the bugs increased as you went through the form. The first step was pretty much bug free, but the final step was completely broken.

Many people who claim that test automation is "too much overhead" either don't understand what test automation is or don't understand what overhead is. If you have to test everything in order to change anything you either have a huge manual testing overhead or have a huge quality liability.


There's a lot of truth to this. I work in a project with a lot of separate assemblies, because we have many applications that share similar functionality. Unit tests are critical to making sure I don't break something for one application while making a change for another. However at the same time, It can be a real pain to load the entire application to test it. Unit tests have actually increased my productivity in some areas where doing a test has about a 1-5 minute overhead (compiling than loading a file etc)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: