<div>My 2 cents would be that if the coverage is not already 100% for these methods then please add the test. If they are redundant then I would agree with Will.</div><div><br></div>The point I would make about coverage for VTK is that it has been dropping down into the 60% range. I've been told that VTK once sported 80%+ coverage. If tests are real unit tests that test functionality and provide coverage then they should be included. If you're looking for tests to create, take a look here. There are 100+ files with 0% to 40% coverage. ;-)<div>
<br></div><div><a href="http://www.cdash.org/CDash/viewCoverage.php?buildid=529419">http://www.cdash.org/CDash/viewCoverage.php?buildid=529419</a><br><div><br></div><div>Something else to note: The parallel testing feature of ctest makes large numbers of tests much less of an issue. On amber10 with parallel testing on it takes just under 5 minutes to run 744 tests. If run serially the same machine takes 25 minutes to do the same tests.</div>
<div><br></div><div><br><br><div class="gmail_quote">On Tue, Feb 2, 2010 at 8:37 AM, David Doria <span dir="ltr"><<a href="mailto:daviddoria%2Bvtk@gmail.com">daviddoria+vtk@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_quote"><div class="im">On Tue, Feb 2, 2010 at 8:19 AM, Will Schroeder <span dir="ltr"><<a href="mailto:will.schroeder@kitware.com" target="_blank">will.schroeder@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

David-<br><br>Looking at the code it seems that vtkPlane::IntersectWithLine assumes a unit normal.<br><br>There are several ways to determine where code is being called/tested from. Grep works, admittedly brute force but effective. Or use a debugger and set a break point at a particular function to see where it is invoked. Fancier methods exist, I'll leave it to the better developers to describe.<br>



<br>While I think it's great that you are considering adding tests, remember that every test takes time to run, meaning that the developer's time to make changes, test and check in code increases. Therefore we are optimally looking for a minimal set of tests (and minimal data) to cover the entire code base. Several years ago Ken Martin (and others of the community) went through the exercise of removing extraneous tests and data because it took way too long to run the test suite.<br>



<br>Will<br><br></blockquote><div class="gmail_quote"><br></div></div><div class="gmail_quote">I agree that the tests should not be extraneous. However, introducing new functions means introducing new tests, right? </div>
<div class="gmail_quote">
<br></div><div class="gmail_quote">The two possibilities are:</div><div class="gmail_quote"><br></div><div class="gmail_quote">1) Find where vtkPlane is currently being tested and add tests for the new functions there</div>

<div class="gmail_quote">2) add TestPlane.cxx</div><div class="gmail_quote"><br></div><div class="gmail_quote">Were you saying that more testing code is time consuming? Or the number of actual tests is what is time consuming? I.e. if (2) is chosen, is that significantly worse than (1)?</div>

<br clear="all">Thanks,<br><font color="#888888"><br>David</font></div>
<br>_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
<br></blockquote></div><br></div></div>