Testing the Waters
Does testing really pay off in the World of software development?
As software developers, we are constantly hounded about the importance of automated testing. We hear diatribes about test driven development, evangelist who swear by unit testing, and coders who claim testing has changed how they work. By now most people in the industry would agree there is a high level of credence to the importance for this type of testing. What I find surprising, despite the apparent benefits, is that most companies don’t do it; and in many cases it is the same who swear by it who aren’t doing it.
So why aren’t more companies utilizing automated testing in their software development? For starters, it takes more time. Of course, it’s easier to write code without companion unit tests for every method created. Writing tests often means writing as much or perhaps more lines of code than the actual solution. With deadlines looming, it is hard to justify this added effort and our tendency is to just get the application working.
Creating unit tests is hard!
Many times, it is challenge enough to just come up with the logic necessary to build an application. Couple that with factoring your code so that it can be easily tested makes the coding effort doubly as hard. One must consider potentially thorny concepts such as interfaces, dependency injection, and mocking. Questions arise such as what to test, how much coverage is preferred, or whether we care to distinguish between pure unit tests or integration tests.
Testing can also be distracting; it’s easy to lose sight of the true goal when you are worried about constructing the perfect test framework. No amount of testing, however, can overcome a solution that fails to meet its original requirements. While on the topic of requirements, with the popularity of agile methodologies, functional requirements are often more fluid. This flexibility in scope potentially sets us up for not only re-writing code, but also re-writing tests to match. Our once perfect suite of test cases can easily become stale.
Despite all the added complexities, why is automated testing now more important than ever? There are two significant reasons why automated testing has become so crucial in the software development lifecycle. First, I point to the ‘rising cost of defects’ paradigm which illustrates the exponentially increasing cost of finding a bug later in the development cycle. A bug discovered through automated testing is far less costly than the same bug discovered during acceptance testing. Later in the process; the end user must capture, document, and submit the bug. The development team must then prioritize, assign, re-analyze, and refactor. All of this is time and money that could have been saved if detected earlier through automated testing.
The second factor that has brought about increased importance on automated testing is the rise of the agile methodology. Nearly everyone it seems is using some form of agile development practices these days. This means that deployments are happening far more frequently than would happen in the old days of ‘waterfall’. With a repetitive release cycle, it becomes paramount that testing be automated. To execute the same test repeatedly is not only tedious but also invites the possibility of excluding certain tests on future runs. Automated testing not only verifies that new code is working but helps keep us covered in terms of regression.
If you or your company are in the business of developing software, ‘test the waters’ and implement automated testing in your development operations. Despite the initial investment in skills, tooling and time, your leap of faith will become apparent as your product matures. Speaking from experience, done right, a solid framework around automated testing will pay dividends before you reach the end of your first release cycle.