I agree with Dave that unless explicitly testing an error condition, it should be flagged an error.<div><br></div><div>To explicitly check for an error you can do something like I did in</div><div>Imaging/Hybrid/Testing/Cxx/TestSampleFunction.cxx</div>
<div><br></div><div>With ITK it is a bit easier because ITK throws exceptions that can be caught by the test program.</div><div><br></div><div>Bill<br><br><div class="gmail_quote">On Wed, Sep 5, 2012 at 3:47 PM, David Cole <span dir="ltr"><<a href="mailto:david.cole@kitware.com" target="_blank">david.cole@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have always thought it should be a test failure (by default) if the<br>
output contains the error string from encountering a vtkError while<br>
running the test. Any exceptions to that rule would be simply to test<br>
the error mechanism itself.<br>
<br>
I know there are some tests that do produce Error messages when I run<br>
them on my machine...<br>
<br>
Seems like those should be test failures, but some are not.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Wed, Sep 5, 2012 at 2:46 PM, Yuanxin Liu <<a href="mailto:leo.liu@kitware.com">leo.liu@kitware.com</a>> wrote:<br>
> Hi, Bill,<br>
>   A separate but related question:  What should be the default behavior of<br>
> tests regarding "ERROR" strings in the standard output?  Currently, unless<br>
> you explicitly do something like set_tests_properties(.... PROPERTIES<br>
> FAIL_REGULAR_EXPRESSION "Error") the tests will pass.  This seems a little<br>
> dangerous to me.<br>
><br>
> Leo<br>
><br>
> On Tue, Sep 4, 2012 at 2:58 PM, Bill Lorensen <<a href="mailto:bill.lorensen@gmail.com">bill.lorensen@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Folks,<br>
>><br>
>> VTK's test code coverage is not very good. Currently it stands at<br>
>> about 62% of the code. I think the pre/post modularization coverage<br>
>> rates are similar.<br>
>><br>
>> One of the lessons we learned from ITK's modularization is that many<br>
>> of the ITK tests were integration/regression tests versus unit<br>
>> tests. Integration/regression tests tend to test multiple classes, but<br>
>> fail to fully cover the code in individual classes.<br>
>><br>
>> Integration/regression tests are certainly important because they test<br>
>> the code as it may be used in an application.  In fact, many of VTK's<br>
>> tests are derived from examples in the original text. Their purpose was to<br>
>> make sure the code actually did what the text said it would do.<br>
>><br>
>> But, having 40% of VTK's code untested is alarming.<br>
>><br>
>> Last year, I picked valgrind defects as my Fall Project:<br>
>> <a href="http://itk.org/Wiki/VTK/SoftwareQuality/Valgrind/Fall2011" target="_blank">http://itk.org/Wiki/VTK/SoftwareQuality/Valgrind/Fall2011</a><br>
>><br>
>> I have adapted some ITK scripts to easily evaluate code coverage for VTK.<br>
>> There is a script in<br>
>> Utilities/Maintenance/computeCodeCoverageLocallyForOneTest.sh that<br>
>> facilitates generating code coverage for a set of unit tests.<br>
>><br>
>><br>
>> For example, running this command from your build directory<br>
>> (instrumented for coverage)<br>
>><br>
>> ../VTK/Utilities/Maintenance/computeCodeCoverageLocallyForOneTest.sh<br>
>> Domains/Chemistry -R vtkDomainsChemistry<br>
>> shows that the Domains/Chemistry module has 67.6% code coverage<br>
>> while<br>
>> ../VTK/Utilities/Maintenance/computeCodeCoverageLocallyForOneTest.sh<br>
>> Geovis/Core -R vtkGeovisCore<br>
>> shows that the Geovis/Core modules has 11.2% code coverage/<br>
>><br>
>> This year's Fall Project is code coverage. This is a bit ironic,<br>
>> because for my GE Six Sigma Project in 1995, I chose code<br>
>> coverage.<br>
>><br>
>> What can you do to help?<br>
>> If you are adding or modifying new classes to vtk, please try to<br>
>> add/enhance the tests for your class.<br>
>> I'll be adding gerrit topics for tests this fall. Please help me push them<br>
>> through the review process<br>
>><br>
>><br>
>><br>
>> Also, I'll be rejecting gerrit topics that add new classes without good<br>
>> unit tests.<br>
>><br>
>> Bill<br>
>> '<br>
>><br>
>><br>
>><br>
>> --<br>
>> Unpaid intern in BillsBasement at noware dot com<br>
>><br>
>><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<br>
>> <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>
><br>
><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<br>
> <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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Unpaid intern in BillsBasement at noware dot com<br><br>
</div>