<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 24, 2013 at 9:55 AM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra">Satish had gcov working before, but it just did not prove to be very useful. First, we generally write tests</div>
<div class="gmail_extra">to look at the workflow for something rather than as a unit test. Second, coverage ignores the path you</div>
<div class="gmail_extra">take to get to a certain line of code. My impression is that these things are only useful when they tell you</div><div class="gmail_extra">lines which are never exercised.</div><div class="gmail_extra">
</div></blockquote></div><br>The classical objective of coverage is to find which lines are never executed, so that you can either (a) eliminate the dead code or (b) write better tests. A less direct objective, which would use the information in a different way, is to detect redundant or mergeable tests. I could be wrong, but I have a feeling that PETSc has a lot of tests that are not really distinct. (The same applies to tutorials. They get cleaned up occasionally, but there have been a lot of copies with only a few lines changed.)</div>
</div>