Topic:
Code Coverage
Presentation by Kiran Ramineni, Technical Director, Verisign Inc. Possible presentation/discussion
subtopics had been:
* What kinds of ‘coverage’ are there?
* If someone asks about 'coverage' provided by your test automation, how
do you respond?
* Basics of using code coverage tools
* What kinds of code coverage tools are available
* Cosiderations in choosing a code coverage tool
* Can coverage be determined without tools?
* Should your coverage goal be 100%? Why/Why not?
Took place on: Wed. September 2 2009 6:30 PM
Attendance: 17
Meeting Notes:
It was noted that Kiran ran the NoVaJUG (Northern Virginia Java User Group)
group meetings for 5 years until 2008
A comment was made that it can be more work to maintain test code than source code
in some cases.
There was discussion of terminology re lines of code, code branches, continuous integration,
automation, and cyclomatic complexity.
There was some discussion re the meaning of 'coverage' and of an article by Cem Kaner
that described more than 100 different kinds of 'coverage'
There was some discussion of an automated java unit test/coverage tool 'Agitate' from Agitar
and there were some comments that it didn't work out well for those who bought it - for example
there were comments that often too much info was produced, or it was difficult to
effectively utilize the output/report info.
There was some discussion re coverage goals and why 100% coverage was often not an
appropriate goal.
Several coverage tools were discussed and pluses/minuses - Cobertura, EMMA, Clover, anbd JCoverage
In doing java code coverage, the advantages of byte code instrumention vs source code instrumentation
were mentioned.
Clover was mentioned as a commercial non-open-source tool, and there was a comment that its reporting
capabilities were even better than Cobertura
There was discussion of the value and effectiveness of static code analysis tools; several
attendees mentioned they had good experiences with them.
There was quite a bit of discussion re the real world benefits of coverage analysis. A point was
made that sometimes its easier to rewrite and improve code rather than try to make better/complicated
unit or automated tests, when the goal was to increase coverage. Some big advantages of
coverage monitoring were cited such as motivated better code and better test automation