<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 28, 2015 at 11:34 AM, David Thompson <span dir="ltr"><<a href="mailto:david.thompson@kitware.com" target="_blank">david.thompson@kitware.com</a>></span> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi David(s),<br>
<br>
I really like the single-header idea, especially the macros for testing whether values match to within a tolerance.<br>
<br>
My concerns are<br>
<br>
1. The C++ Testing/Rendering/vtkTesting.h class which provides (or now that we have ExternalData, provided?) access to baseline images doesn't seem to fit into the FIXTURE macro. Is there a way to integrate it? Or a way to extend the vtkTesting class to be more usable by including methods similar to your macros?<br></blockquote><div><br></div><div>The quick answer is, no, as it stands vtkTesting wouldn't fit into a UnitTest.h fixture.  Your second suggestion sounds like the better approach: add unit test macros and their associated code to vtkTesting.</div><div><br></div><div>I'm very fond of using macros, rather than methods, for the unit-test assertions because a macro can easily print out the line number in the test program where an assertion failed. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. One thing I dislike about most/all of the C++ test frameworks is that the error messages are assumed to be fixed and the methods often do not present a way to include the incorrect result as part of the failure message. It is nice that your macros include that. However, given that tests often fail on machines I don't have access to, it is really nice to encourage people to write useful messages. Macros like CHECK_CLOSE would be better if they accepted a message as a final argument, especially if the argument was passed to a std::ostream object the way vtkGenericWarningMacro() does so that people can (are forced to) provide more context about where the two numbers being compared come from.<br></blockquote><div><br></div><div>Something like that could be accommodated.</div><div><br></div><div>I can see about putting together a merge request that makes vtkTesting more amenable to unit tests, rather than introducing yet another way of creating tests for VTK.</div><div><br></div><div> - David</div></div></div></div>