I would say just the reverse; that statement coverage is a sub-class of basic block coverage.

Thursday, May 14, 2009 12:26 PM by I.M.Testy

Based on the defintion of a basic block, can it be a sub-class of statement code coverage testing?

Thanks,

Javier Andrés Cáceres Alvis

Blog Personal: http://speechflow.spaces.live.com/

Blog Intel: http://software.intel.com/en-us/blogs/author/javierandrescaceres/

Monday, May 11, 2009 10:23 PM by JavierCaceresAlvis

Tuesday, April 07, 2009 7:28 PM by notes and rants

Thanks for sharing your thoughts, B.J!

Monday, March 16, 2009 3:14 AM by chai

We must remember that block coverage is a very simple measure of structural coverage, but it is usually sufficient for unit level testing. It certainly is not a comprehensive measure structural testing effectiveness of complex code. Of course, the greatest value of measuring block and arc coverage of the source code is to help the tester identify areas of the code that have NOT been tested.

Also, code coverage (block, decision, condition, path, etc.) can be measured. Unfortunately, many people assume code coverage and test coverage are synonomous. However, I disagree and think that assumption is very dangerous and misleading. In the book How We Test Software At Microsoft I try to explain how a few tests can achieve high code coverage measures without effective testing of the algorithm.

Unlike code coverage measures which are based on various control flow patterns there is no effective way to accurately measure test coverage. (This is a discussion unto itself, so I will leave that for a later post.)

Unfortunately, I don’t have any hard figures that I can share; however, Watts Humphrey has presented some interesting data in his TSP/PSP documentation and studies. I will also say that the Agile community puts a huge emphasis on the importance of unit testing for good reason, and inside Microsoft unit testing is a best practice in our product groups. In fact, I can’t think of any situation where unit testing would not be considered a best practice. I have encountered a few developers who were resistant to doing unit testing, and I just hand them a copy of Pragmatic Unit Testing by Andrews and Hunt and remind them they get paid for writing code that works, not code riddled with bugs. Not that I expect them to find all their bugs (because they won’t), but I don’t expect them to simply sit in their office and throw completely untested crap code at testers. (Of course, most developers that I know are professionals who are just as concerned with the quality of their work as are the testers who help assess the overall quality through more extensive testing.)

One way to convince management to schedule time for unit testing is to measure the cost of build breaks. At Microsoft we have daily builds in most of our product groups. If an untested dev check-in caused a build break the costs were pretty high. In one case that I am familiar with one team went from several build breaks per month to less than one build break per quarter by implementing a regimented unit testing strategy. This literally saved hundreds of thousands of dollars within the first year. Management really pays attention to numbers when there is a dollar sign in front of them.

Friday, March 13, 2009 2:33 AM by I.M.Testy

To this end, I’m inclined to believe that the availability of “on-the-field” ROI figures showing the benefits of unit tests in large development projects would go a long way in winning the debate on whether it is worthwhile to perform unit tests as a planned and budgeted activity.

It would be great if you could shed some light on this topic — in many cases this may translate to embark on an almost sisyphusian task — but I’m somehow optimistic that you may have some figures to share

Cheers,

Chai

P.S.: I haven’t yet read your book (but your posts and Alan’s are compelling me ever more to

order a copy

Thursday, March 12, 2009 4:48 AM by chai