NCoverExplorer HTML Coverage Reporting

[kiwidude]

I've had a couple of users ask whether NCoverExplorer might ever offer
the ability to generate HTML reports of code coverage. An example of
the potential sort of output (including the source code highlighted) is
shown by Clover here:
http://www.cenqua.com/clover.net/eg/nunit/report/index.html

I'm interested to know just how much demand there is for this feature.
It looks pretty but personally I doubt I would make use of this
particular report - html pages by their nature are static and the
hundreds or thousands of pages generated are virtually guaranteed to be
out of date immediately as the code changes. I'm open to being educated
though - what usage would you make of such a feature if NCoverExplorer
offered it, or is it just a "nice to have"?

The one type of reporting I have found useful is the top summary
section produced by the coverage.xsl that comes with NCover. The
downside of the XSL approach is it is just way too slow on large
coverage files. It could be fairly easy for NCoverExplorer instead to
produce a static HTML summary page showing the graph percentages. This
report could then be included as a CruiseControl build artifact (if I
make a console driven NCoverExplorer version) or via e-mail.

Does this have any appeal? If so, what sort of reports would you like
to see (e.g. assembly coverage summary only or namespace/class
summary). How detailed and customisable do the report(s) need to be?

All input for and against welcomed!

Thanks,
Grant.
http://www.kiwidude.com/blog/

[Andrew Stopford]

Hi Grant,

 

The only use that I could see for this would be within a CI build like CCNet as you say. However NCover already has reports via a XSL transform for CCNet.
 

Andy
 

[Kipp Howard]

During our build, we generate the ncover xml and place it on our build machine's web server and send a URL to that report so that anyone can see the progress.  Of course the location where we place the report contains the .xsl file provided with ncover.  Having said that, we would probably only run the report in the nightly build as it is somewhat similar in nature to creating the ndoc documentation (in terms of # of files) which is a somewhat lengthy process due to the # of classes we have.

Now, comparing the utility of your report verses the one provided with ncover, I much prefer yours as it is very clear what is going on and you have access to see what code was covered.

So, I would very much like to see a way to produce this report, in an automated fashion.  I don't want to have to bring up NCoverExplorer to produce it though.  A command line invocation would be required.

After thinking about this a bit, it seems this is more like a separate NCoverExplorer2Html tool.

PS: NCoverExplorer has changed the way I work with unit tests (for obvious reasons).  Thanks for all of the work.

On 3/16/06, kiwidude <grant...@gmail.com> wrote:

I've had a couple of users ask whether NCoverExplorer might ever offer
the ability to generate HTML reports of code coverage. An example of
the potential sort of output (including the source code highlighted) is
shown by Clover here:
http://www.cenqua.com/clover.net/eg/nunit/report/index.html

I'm interested to know just how much demand there is for this feature.
It looks pretty but personally I doubt I would make use of this
particular report - html pages by their nature are static and the
hundreds or thousands of pages generated are virtually guaranteed to be
out of date immediately as the code changes. I'm open to being educated
though - what usage would you make of such a feature if NCoverExplorer
offered it, or is it just a "nice to have"?

The one type of reporting I have found useful is the top summary
section produced by the coverage.xsl that comes with NCover. The
downside of the XSL approach is it is just way too slow on large
coverage files. It could be fairly easy for NCoverExplorer instead to
produce a static HTML summary page showing the graph percentages. This
report could then be included as a CruiseControl build artifact (if I
make a console driven NCoverExplorer version) or via e-mail.

Does this have any appeal? If so, what sort of reports would you like

to see ( e.g. assembly coverage summary only or namespace/class

summary). How detailed and customisable do the report(s) need to be?

All input for and against welcomed!

Thanks,
Grant.

--
Kipp Howard
kipph...@gmail.com

[kiwidude]

Hi Andy,

The problem with the existing CCNet approach is the size of the
buildlog files for large projects. Anyone who has tried transforming
25-40MB files knows just how slow and painful that is.

I'm thinking "NCoverExplorer-Console.exe" could instead have a couple
of options via command-line switches, to either produce a summary xml
for inclusion in the build logs/standard CCNet approach (with a new
stylesheet obviously), or generate the html directly. This should
result in an xml file of just a few kb instead of tens of megabytes. My
personal usage of code coverage in build logs is just to look at the
top level summary information - this would give us the snappy response
we want.

Regards,
Grant.

[kiwidude]

Hi Kipp,

So that's a yes vote then for having the full coverage report with
source code? Given that each of the classes would be a separate html
page you face the same problem as others for large projects - a ton of
files being generated. Would you store these in a separate folder for
each build or overwrite to represent the latest coverage?

Agreed it is a separate tool - as I intimated in my response to Andy I
have created an NCoverExplorer-Console.exe already. It uses the same
core as NCoverExplorer which means it can apply all the same coverage
exclusions etc.

Its current implementation actually does something else based on a user
request - it will return a failure error code if the coverage does not
meet a certain threshold, allowing them to fail the CC build. However I
intend to extend this to do some console based reporting as well.

Regards,
Grant.

[Kipp Howard]

On 3/19/06, kiwidude <grant...@gmail.com> wrote:

So that's a yes vote then for having the full coverage report with
source code? Given that each of the classes would be a separate html
page you face the same problem as others for large projects - a ton of
files being generated. Would you store these in a separate folder for
each build or overwrite to represent the latest coverage?

We would probably store all of the files on a per-build basis.  Not sure how much space this would take (probably a lot) but since disk space is cheap, it is probably not a big deal. 

Of course, making different degrees of completeness would be useful.  Although, I'm not entirely sure exactly what a partial report would be.  A summary and the complete report are pretty clear. 

--
Kipp Howard
kipph...@gmail.com

[Mowee]

I thing that both ways should co-exist in the (new) console tool, I
mean 1) all source files with coverage highlights per lines (like
clover.net does), that will be the FULL, complete, report, and 2) the
existing various summaries (Module summary and\or Namespace summary).
I agree with Kipp that we would like to have it on a per-build basis,
and storing it on a file server for sometime.

--mowee--

> ------=_Part_102_1163642.1142801081047
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> X-Google-AttachSize: 1239
>
> On 3/19/06, <b class="gmail_sendername">kiwidude</b> &lt;<a href="mailto:grant...@gmail.com">grant...@gmail.com</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> So that's a yes vote then for having the full coverage report with<br>source code? Given that each of the classes would be a separate html<br>page you face the same problem as others for large projects - a ton of<br>files being generated. Would you store these in a separate folder for
> <br>each build or overwrite to represent the latest coverage?<br></blockquote></div><br>We would probably store all of the files on a per-build basis.&nbsp; Not sure how much space this would take (probably a lot) but since disk space is cheap, it is probably not a big deal.&nbsp;
> <br><br>Of course, making different degrees of completeness would be useful.&nbsp; Although, I'm not entirely sure exactly what a partial report would be.&nbsp; A summary and the complete report are pretty clear.&nbsp; <br clear="all"><br>
> -- <br>Kipp Howard<br><a href="mailto:kipph...@gmail.com">kipph...@gmail.com</a>
>
> ------=_Part_102_1163642.1142801081047--