Are your developers unit testing?
- 21 September, 2009 17:22
- Comments 6
The project was already two weeks late. The team had been working on it for months and management was pushing for completion. Joe was conducting some last minute testing on the latest beta version when, suddenly, everything came crashing down. The screen flashed an error message:
"Error 3942: Un-expected failure in parser".
How was this possible? This problem had been fixed weeks ago!
Does that scenario sound familiar? It shouldn't - recurring bugs in software development are normally a sign of a problem in the development process. It usually happens when additional code is added somewhere to deal with a special case, which introduces a bug in the normal code path. You eventually notice and fix the bug, only to have a similar bug re-appear later when another special case is added.
Unit testing is one method used by development teams to solve this problem. At its core, unit testing is about writing a series of independent small tests to check that individual functions within the code base are doing the right thing.
Unit testing also provides an example of how a function should be used. It is quite common for documentation to become outdated as the code it refers to is updated or modified. A unit test however, will start failing if the code it is testing differs too much from what it did originally, allowing developers to catch and document accordingly.
Refactoring is another situation where unit testing is useful. Sometimes, developers must change how a function is implemented - whether due to an architectural problem or slow code. This often results in large changes in the code base. Unit tests can be used to check that no bugs were introduced when the change occurred.
One of the great things about unit testing is that you can gradually introduce it into your code base. As developers fix existing bugs or add new features they can add new tests. As time goes on, the percentage of the code base covered also grows.
Take, for example, a code base to return a state from a postcode entry. Here are a few unit tests:
- a sample NSW postcode
- a test for a sample ACT postcode (same first number but not the same state)
- an invalid postcode within the 0001 to 9999 range
- an invalid postcode with letters in it.
Whenever the code is modified, you can run unit tests to ensure any existing functionality hasn't broken. In our example, the postcode function may be modified again to deal with postcodes that don't match their state prefix (such as postcodes in border areas). The unit tests could be used to check that the existing functionality is still working correctly.
Continuous Integration
Unit testing isn't the solution to every problem, however. Although it can be used to solve a class of problems, it will not be appropriate for testing whole programs, or integration into systems. And it is generally unable to detect performance problems such as slow code that nevertheless performs the correct action. It is only a problem if you become over-reliant on this type of testing. The rest of the time, unit testing is a great tool to have in the developer toolbox.
Email Computerworld or follow @computerworldau on Twitter.
- Bookmark this page
- Share this article
- Got more on this story? Email Computerworld
- Follow Computerworld on twitter
-
TPG faces customer backlash over slowed net speeds
-
CSIRO claims world's fastest wireless link
-
CeBit 2012: Social media a legal minefield
-
VOIP a wake-up call for global phone competition
-
CeBIT 2012: Will NBN speed up freight delivery times?
Comments
Enigmatic
This is a wonderful concept in an ideal world, and every developer can sit back and let their eyes glaze over as they dream about such a thing, but the reality is that the fault is not in the development process but in the MANAGEMENT process.
To be able to write and maintain unit tests like these not only takes time but also takes a stable design. The number of times over the last 15 years that I have seen management PUSH to get something done quicker, at the expense of unit testing is shocking. Whenever estimates are given that include unit testing they scoff at them and even though they have never cut a line of code in their life they swear it doesn't take that long.
What is worse is that because there is this long history of management cutting corners to make themselves look good (see how quickly *I* delivered that?), the customers have now been conditioned to believe that software development is a simple thing that doesn't require a lot of time or effort. So when you present to the customer the total time/cost of the project they too scoff at it saying it shouldn't cost that much or take that long.
So as long as there is a mentality by both management and customers to constantly underestimate the time/effort of good softare development, we will always be in a position where the first thing to go includes things like unit testing because to them, its wasted money, they cannot see the benefits of doing it when the time taken to write the unit tests is not going towards their SLOC count or towards productive code.
So thanks for the effort Pascal, but sadly it is academically sound, but practically unworkable due to short sighted management and poorly conditioned customers
Anonymous
I cannot believe that any self respecting programmer would not thoroughly unit test his/her code before making it available for system testing. It beggars belief!
pasc
I completely realise that complete coverage is hard - both from a time perspective and from a "convincing management it's a good idea" perspective. For me however, the great thing about unit testing, is that it's easy to start. I've had some very good results in some of our code libraries by just writing unit tests for bugs that had been reported, and then expanding them a tiny little bit for similar cases where I could see that things could go wrong.
Unit tests can also be a good way of loosening up the writer's block you sometimes get when you're trying to find the 'right' solution to a problem.
Enigmatic
Your preaching to the chior ;-)
When your manager asks you what you did for the week and you say "unit tests" you don't get a good response. We all know and understand their benefits, its changing the culture so that managers can accept them as a necessary (and beneficial) part of the software lifecycle that is the problem.
The sooner the code is out the sooner it is in a "maintenance" cycle, which gives the manager a big TICK for having completed the project. If there is a lot of rework required they simply pass the blame onto the developers and walk away like they did their job successfully. I have seen this happen over and over in the last 14 years.
Sadly I think this is a flow on effect from restrictive budgets. Companies tend to feel they only require project management, and that they can "skip" the engineering function of software development. Without this control on quality, the only factors that remain are time and budget, which is the primary concern of the project manager. If faced with two choices, they will generally go for the cheaper one even if it had long term detriments simply because their measure of success as a manager is done by achieving timelines and saving money.
Enigmatic
To Anonymous,
I can't believe
To Anonymous,
I can't believe any self-respecting manager would ever allow code to go without being thoroughly unit tested and yet it is always the last thing on their minds, the first thing they cut and the first thing they complain about. They want it done (because they know it should be), but they don't want to spend the time/money to do it.
Bad I know, and with each contract I try to impress upon them its importance, but ultimately the decision lies in their hands and in general (about 60-70% in my experience) they will leave it until the end if at all. About 30% tend not to care as long as you can deliver it within the timeframe you have estimated (in which case you ALWAYS provide unit tests), and sadly 10% are pro-active and set aside an appropriate amount of time for doing this and even have it written into their policies and procedures.
I would like to think that I am an unusual case, but I have worked in the private sector, government, defense, large companies, small companies... across the board and I see this all the time.
TheCFO
Any developer not doing unit testing and relying on QA for unit testing is going to be the scapegoat, and expendable. Throwing untested code "over the wall" is just not acceptable, you better make it part of the schedule or all of your weekends. You can't test everything, but the unit test is on the developer.
Post new comment