Seriously? What are the reasons? Why would you not invest in test suites? Is it the cost of starting to do it? The investment in time when you start? Learning curve?
Some background:
I’ve been working with this third party software company for the past 18 months now. It seems every patch we get to fix 3-4 bugs, produces at least 1-3 more bugs. Some of them critical. We’ve had data get wiped out due to bugs in the software, data not get imported, etc.
In this day and age, unit and integration testing isn’t all that difficult. So why do we continue to choose not to do it?
Yes, there is an upfront cost to implementing it, but that cost literally pays for itself over and over again when you get to the point of not dealing with bug reports! (at least that has been my experience).
Anyone else have this question lingering in their minds? Or can shed some light as to why you might not write test suites in your software?
That is a great question. The upfront cost is very high to write those test codes. Usually, if you testing # line code > source # line code then it’s a good sign. That is 2x the cost and time to write a good test cases. Not all are rainbows and unicorns for maintaining the test suites. There are many cases that test fails due to false positives or due to requirement change. In this cases, not only do you have to refactor your test code…there’s a good chance you’ll have to fix test cases you didn’t write. Understanding other people’s test may take time if there’s not much comments. Here’s an example where I would not write Test Suites. It’s when I’m building a prototype where requirements could change at any moment’s notice. Sometimes having a test case could be the reason to not improve existing code. If you have a much better architectural design then you would have to re-write all the existing test codes. By all means, I am with you that most project should write test cases but most of upper management only cares about code ‘working’ than worrying about code ‘quality’.
Yeah, I can buy into that. I also know where I work right now we do not have any Test Suites on our legacy application (which is slowly being transitioned into a new architecture over the next 5 years). The way the legacy system was designed, made it nearly impossible to write any tests for it without wanting to scratch your eyes out. The new architecture does have tests written.
When prototyping, I generally do not write tests either, because I’m more interested in whether an idea/concept works than I am actually implementing it. Once I prove it works, and I start the actual project, I’ll use TDD and write my tests up front and follow it up with the code.
Any new work I do has tests associated to it anymore. And although when I started doing that 3 years ago, I was programming 2-3 times slower because I was learning how to do it. It took me a good 6 months to a year before I felt I was back to my typical speed, but that time was well worth it.
