Re: Bug 38840 - Adding coverage analysis to unit tests

2012/8/24 John Smith <lbalbalba@gmail.com>:
> On Fri, Aug 24, 2012 at 5:28 PM, Stephan Bergmann <sbergman@redhat.com> wrote:
> > In a sense, even during the tests, very much of our code is executed "by
> > accident" rather than due to dedicated test code calling it:  Especially the
> > subsequentcheck stuff contains checks that are not simple unit tests, but
> > start of a complete soffice.bin process, causing "unintended" testing of
> > large parts of the infrastructure code anyway.
> Whether code gets tested 'unintended' or not during your 'tests' is
> really not relevant, is it ? Only if the code gets executed or not ?

Hey all,

As far as I learned in my Softw. Eng. courses, the main intent of this
type of code coverage is _not_ to show which parts are under test but
primarily to point out which parts are not tested at all so far. As
<https://en.wikipedia.org/wiki/Code_coverage#In_practice> states:
"This process allows developers and quality assurance personnel to
look for parts of a system that are rarely or never accessed under
normal conditions (error handling and the like) and helps reassure
test engineers that the most important conditions (function points)
have been tested."

And as one can (now fortunately) see there are still quite some lines
of code that are not touched during the tests... But now we all have a
much better overview what parts are exactly missing tests -- which at
least from my perspective is much better than just guessing and gut
feeling! Thank you very much for all your great work so far, John!

Of course, in future, every bug should get a unit test (at best even
before starting to fix it) so that regressions are easier get caught
;-)
In addition, it would be also good, to have two reports: (1) with only
the unit test coverage and (2) one where all test, including
integration tests etc., were executed.

Just my idealistic university viewpoint :-)

ATB,
Philipp