Why Unit Testing?
Data from projects worldwide says that in spite of the progress we have made as an industry, many software projects fail or are completed late or over budget. As the pace of business increases, software development teams need to respond faster to deliver the software the organization needs.
Many Java development teams want to be much more agile, and are trying to meet three related goals:
Faster time-to-market: Too many development and QA cycles are consumed coddling fragile legacy applications (Yes, even with Java – legacy code is not just for COBOL anymore. "Fragile" refers to any code created without the detailed tests that make it easy to change the code with confidence). The drag from ongoing problems in legacy code slows down the organization, making it harder to meet its commitments.
Higher quality: Teams often release code with more bugs than they would like, leading to longer and more expensive QA cycles and more bugs delivered to end users. There's been too much focus on testing to remove bugs, instead of building software without bugs in the first place.
More flexibility: Many legacy systems are too fragile and too inflexible to enhance. It’s hard to be agile as a business if you’re afraid to change the code on which the business depends.
What can you do to build better code and make the code that you already have better - so that you can deliver more software, faster?
The bottom line? Your team is under a ton of pressure, and it feels like there’s no way out. But is help possible? Let’s consider how software development often works now, and how it could work better.
Inefficient development processes make software late
Much software is coded, tested in an ad hoc fashion, then handed off to the QA team, which finds bugs and reports them to developers. But it wastes time and money to fix bugs so late in the process. Industry research shows that the cost to fix a defect jumps by an order of magnitude at each phase of the software lifecycle. That means it can cost up to 100 times more to find and fix a bug when QA is testing vs. when developers are unit testing. This inefficient workflow makes software late and expensive.
Source: Applied Software Measurement, Capers Jones, 1996
Growing complexity makes software buggy
With the growing size of Java software projects, and the complexity of testing object-oriented code, today’s applications often have millions of combinations of states and paths. It’s impossible for QA to even imagine (let alone test) every possible state, every possible data value, and every possible path through the code.
System testing will always miss something. The more complex the system, the more defects will likely be missed. This growing complexity contributes to software that isn’t sufficiently tested, and is eventually released with an unknown number of bugs.
Band-aid fixes make software inflexible
Developers know from experience the code in legacy apps is fragile. They know this because fresh bugs spring up every time they touch it, and yet they lack the tools to efficiently catch these regressions.
Naturally, instead of redesigning or refactoring a legacy app, a developer must instead resort to "localized fixes" (also called hacks, kludges, and band-aids) in an attempt to cause as little damage as possible. Even when a developer is very careful, regressions often creep in, many of them not noticed until a customer reports an issue. Over time, the accumulation of these local fixes makes legacy code even harder to enhance. The more hacks, the less flexibility.
Unit testing is part of the solution
Unit testing is an effective approach that improves time-to-market, quality, and flexibility. The key idea is that each piece of code needs its own tests and the best person to test that code initially is the developer working on it. Enabling developers to test their code as they write it encourages quality to be built in from the start. Having unit tests makes it easier and safer to modify the code because the tests document and protect the intended behavior and will quickly catch any regressions.
Automation helps get it done
Unit testing is the right thing to do, but it isn’t easy. Ideally, each developer should produce a set of tests to validate each individual method and class as they are being written. It takes time to identify the high-risk areas, write tests, run tests, monitor the results, and pinpoint further areas for testing. And it’s tough for any human being to imagine the unexpected, the things they never counted on happening. Automation of aspects of unit testing can help greatly.
Why you need AgitarOne
The award-winning technology in AgitarOne – the only comprehensive, fully integrated, automated unit testing solution available – supports the move to unit testing. You can get started with AgitarOne at any stage of your development process, and see immediate results. You can cut bugs from development to QA up to 90%, drive quality upstream in your development process, and dramatically transform your costs and cycle time. The resulting code is far easier to maintain and enhance in the future, helping you respond with the software your business needs, when it is needed.