[prev in list] [next in list] [prev in thread] [next in thread]
List: vtk-developers
Subject: Re: [vtk-developers] VTK Code Coverage
From: Bill Lorensen <bill.lorensen () gmail ! com>
Date: 2012-09-18 21:43:21
Message-ID: CADZJ4hNk6hvYuYuRqGYh-bEKbsDGOXGOA5=HQF-jh3xdnL-juA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
My main concern is that vtk coverage is very low, and unacceptable.
I would rather spend time on improving the coverage. If others want to
improve the process, that is great. Past experience shows that too much
time is spent on testing process and too little on actual testing.
I say go for it, but I will concentrate in test coverage.
Bill
On Tue, Sep 18, 2012 at 5:34 PM, David Doria <daviddoria@gmail.com> wrote:
> On Tue, Sep 18, 2012 at 4:23 PM, Bill Lorensen <bill.lorensen@gmail.com>
> wrote:
> > Folks,
> >
> > I mentioned earlier that my Fall/Winter VTK project is improving code
> > coverage.
> >
> > I'm starting with some low hanging fruit, namely Common/Core which has 19
> > files flagged by cdash as low coverage:
> > http://open.cdash.org/viewCoverage.php?buildid=2568829
> >
> > For example I just pushed this topic to gerrit that addresses testing for
> > vtkTimePointUtilities, a class that has 0 coverage. I'm pretty sure there
> > are bugs in this code, mainly surrounding boundary conditions that would
> not
> > affect its usage, whatever that may be.
> > http://review.source.kitware.com/#/t/1295/
> >
> > But rather than rant, I'll ask the community to review the gerrit topics.
> >
> > Bill
>
> This sounds like a great project.
>
> If you are going to be adding tons of tests, can we discuss a
> standardized format for them? The current method of putting everything
> in Test[TestName]() seems very error prone (accidental use of
> previously defined variables, name clashes, etc) and is definitely
> hard to read. I have pushed a new patch set that breaks some things
> out into functions. Is there any problem with doing it like this? It
> seems much more readable to me. In this case these functions are all
> void (because the content doesn't get checked for failure anyway), but
> of course they could return 'int' so that 'return EXIT_SUCCESS' could
> be ANDed with the other tests to produce the final test return value.
>
> Thoughts?
>
> David
>
--
Unpaid intern in BillsBasement at noware dot com
[Attachment #5 (text/html)]
My main concern is that vtk coverage is very low, and \
unacceptable.<div><br></div><div>I would rather spend time on improving the coverage. \
If others want to improve the process, that is great. Past experience shows that too \
much time is spent on testing process and too little on actual testing.</div> \
<div><br></div><div>I say go for it, but I will concentrate in test \
coverage.</div><div><br></div><div>Bill</div><div><br></div><div><br><div \
class="gmail_quote">On Tue, Sep 18, 2012 at 5:34 PM, David Doria <span \
dir="ltr"><<a href="mailto:daviddoria@gmail.com" \
target="_blank">daviddoria@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="HOEnZb"><div class="h5">On Tue, Sep 18, 2012 at \
4:23 PM, Bill Lorensen <<a \
href="mailto:bill.lorensen@gmail.com">bill.lorensen@gmail.com</a>> wrote:<br>
> Folks,<br>
><br>
> I mentioned earlier that my Fall/Winter VTK project is improving code<br>
> coverage.<br>
><br>
> I'm starting with some low hanging fruit, namely Common/Core which has \
19<br> > files flagged by cdash as low coverage:<br>
> <a href="http://open.cdash.org/viewCoverage.php?buildid=2568829" \
target="_blank">http://open.cdash.org/viewCoverage.php?buildid=2568829</a><br> \
><br> > For example I just pushed this topic to gerrit that addresses testing \
for<br> > vtkTimePointUtilities, a class that has 0 coverage. I'm pretty sure \
there<br> > are bugs in this code, mainly surrounding boundary conditions that \
would not<br> > affect its usage, whatever that may be.<br>
> <a href="http://review.source.kitware.com/#/t/1295/" \
target="_blank">http://review.source.kitware.com/#/t/1295/</a><br> ><br>
> But rather than rant, I'll ask the community to review the gerrit \
topics.<br> ><br>
> Bill<br>
<br>
</div></div>This sounds like a great project.<br>
<br>
If you are going to be adding tons of tests, can we discuss a<br>
standardized format for them? The current method of putting everything<br>
in Test[TestName]() seems very error prone (accidental use of<br>
previously defined variables, name clashes, etc) and is definitely<br>
hard to read. I have pushed a new patch set that breaks some things<br>
out into functions. Is there any problem with doing it like this? It<br>
seems much more readable to me. In this case these functions are all<br>
void (because the content doesn't get checked for failure anyway), but<br>
of course they could return 'int' so that 'return EXIT_SUCCESS' \
could<br> be ANDed with the other tests to produce the final test return value.<br>
<br>
Thoughts?<br>
<span class="HOEnZb"><font color="#888888"><br>
David<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Unpaid \
intern in BillsBasement at noware dot com<br><br> </div>
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtk-developers
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic