The most fundamental principle behind Agile is to make software in an iterative fashion. What this means is – in every iteration, you add some more business value (read features) to the product. This works smoothly only if you are committed to only “moving forward” i.e. you never break existing features- even if you have to refactor (which is actually strongly encouraged).
Achieving this level of sophistication isn’t easy. It comes with a strict discipline. To be able to concentrate on the future, you need to be sure that your past is secure. In other words, as a developer, I should have to worry about only what I did today , without worrying about the impact on what I did yesterday.
This is where a good set of automated unit test cases come in. They help you to make sure that your code is well guarded, detect breakages in time and help you prevent broken windows.
It’s like going to a battlefield with armor. You definitely don’t want to go to a battle without protection (unless maybe you are Chuck Norris
).
Here is a thought…If you are going to a battlefield- wouldn’t you want to check how good your armor is ?
And this is where Code coverage tools come in
If test cases are like armor- having unit test coverage is like checking your armor to make sure that you can depend on it.
The question isn’t how much coverage do you have? The question is – how well are you covered ? It is not a quantitative but a qualitative question . Without code coverage tools- you will simply have a number e.g. I have 500 test cases in modules X and 1100 test cases for module Y. This doesn’t give you ANY idea how well you are covered. Some modules may be more sensitive to changes and others may be more prone to defects. Code coverage tools give you insight- as to what exactly is covered and how well it is covered. This empowers you to decide where you should be concentrating on increasing coverage . To go back to the armor example- what would you be more concerned about- your pinky? or your chest?
Risk mitigation
An iterative development model adds another dimension to the problem. When you add more code, how do you know what risk have you imposed on existing code ? Test cases may help you detect breakages- but they alone don’t help you understand the increase of risk on the existing code.It’s quite possible that the code that you added today may have reduced your existing coverage.
E.g. You have a method calculateFun () which takes in an enum – DaysOfWeek. To start with there were only 5 days defined in this enum . At that point of time- the method can handle all the 5 days available in the enum. Down the road, the product owner wants to add some new features – calculateTVTime() for the weekend. So you add two more days to the enum. You now add test cases for calculateTVTime () and are feeling very happy about that. Which is all good- except that you have now reduced your covergae for calculateFun (). It can now take two more enum values while your existing method only handles 5possible days.
The question is – how do you detect this slippage in coverage ? This is where code coverage tools help. In the above example, if you were to run such a tool – after you have added two more enum values, it will report back to you – that your coverage on the method calculateFun() has now decreased from 100% to something less than 100%. At that point- you can then decide whether its worth the while to add more test cases or not.
How do they work ?
These tools use reflection features offered by your programming language. The code is instrumented to add more detailed information and then executed against the test suite. The tool than analyzes what all paths in the code were executed and what possible paths were missed. Accordingly it generates a report detailing % coverage for every class.
Unit test coverage tools for Java
There are bunch of open source and commercial tools available for Java which can calculate the coverage for you. I have personally used Cobertura and have been fairly satisfied with it.
The image on the left is a sample report generated by Cobertura. It tells you the line and branch coverage you for the code. Note the last column – which is the complexity of the class. This further helps you appreciate that the more complex classes are adequately covered.
The image on the right shows you the exact lines which are missing coverage. In this case it is a typical setter method, and it’s probably not very important to cover this particular method. However, if the method was more complex- you may decide to cover it more.
A good automation testing strategy is essential for adopting Agile. And it’s tools like code coverage which keeps your coverage honest.
So go ahead, cover your code and know what you have covered.
Recent Comments