[Insight-developers] Proposal: Adding ImageCheck class to Insight/Testing/Code/Common

[Stephen Aylward]

All of ITK (i.e., any file including filters, directories, and
CMakeLists.txt) is considered the ITK API.

The includes stuff in Utilities, Testing, etc.

You cannot predict how ITK is being used by others except to assume that
others are using it as-is, in its entirety.    Just as Luis says "if it
isn't tested, then its broken," for backward compatibility, "if its been
released, someone is depending on it."

s

On Thu, Feb 12, 2009 at 1:25 PM, Bradley Lowekamp <blowekamp at mail.nih.gov>wrote:

>
> On Feb 12, 2009, at 12:10 PM, Bill Lorensen wrote:
>
> It verifies that the class has progress if I recall. It also exercises
> the PrintSelf method of a class. This often uncovers uninitialized
> member data.
>
>
> Yes you are right. It does verify that the filter has progress and throws
> an exception if it doesn't. I do wonder the value of just printing stuff. I
> mean if it changes, the test will still pass. Do you even know if your
> filter was executed?
>
> I just saw a couple of example of tests which just relied on the text
> output being verified and do not fail when things start to go work.
>
> Certainly if we add test helpers, they will need to be backward
> compatible once we release them. For example, Slicer3 uses
> itkTestMain.h. I think other test helpers will be used by other large
> packages that use itk like orfeo.
>
> I may have been premature about moving files. If the UseITK.cmake.in
> is updated to have the new include directories and libraries, then we
> may be OK.
>
>
> Are these files currently included by UseUTK.cmake?
>
> If they are not, is it still part of the API?
>
>
>
> On Thu, Feb 12, 2009 at 11:49 AM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>
> So the Testing directory needs to be backwardly compatible too? I am having
>
> difficulty figuring out what that would mean in the context. And the
>
> motivation.
>
> I have looked through a dozen tests that use the FilterWatcher. I think
> it's
>
> a POINTLESS class for testing. It is not used for verifying anything and
>
> does not change the return value of a test (in the cases I looked at).
>
>
>
> On Feb 12, 2009, at 11:38 AM, Stephen Aylward wrote:
>
>
> I agree that existing ones cannot be moved, but they should be converted to
>
> shells that point to the main code in the new directory, and moving forward
>
> the new directory should be used.
>
>
> Backward compatibility need not stop progress.
>
>
> s
>
>
> On Thu, Feb 12, 2009 at 11:37 AM, Stephen Aylward
>
> <Stephen.Aylward at kitware.com> wrote:
>
>
> Insight/Testing/Tools
>
> Insight/Testing/Utilities
>
>
> Insight/Code/Testing
>
>
> The last one is particularly appealing to me, but I'll admit that it may
>
> be confusing to the uninitiated.
>
>
> Stephen
>
>
>
> On Thu, Feb 12, 2009 at 10:29 AM, Luis Ibanez <luis.ibanez at kitware.com>
>
> wrote:
>
>
> Yes, indeed,
>
> this suggested class will be one of many to come in a larger
>
> testing framework. You could imagine similar classes for
>
> ImageRegions, Indices, Points, Transforms....
>
>
> Maybe creating a central directory for them could help to
>
> group them in a more visible way.
>
>
> We could have, for example, a directory:
>
>
>
>     Insight/Testing/Framework
>
>
> where we will move things like
>
>
>     * FilterWatcher
>
>     * PipelineMonitor
>
>     * ImageChecker (hopefully with a better name)
>
>     * ImageRegionChecker....
>
>
> Along with them we could also add a family of
>
> .cmake files defining useful CMake macros.
>
>
>
> Regards,
>
>
>
>    Luis
>
>
>
> -----------------------
>
> Gaëtan Lehmann wrote:
>
>
> Hi,
>
>
> Le 12 févr. 09 à 00:34, Luis Ibanez a écrit :
>
>
>
>  Please let us know what you think,
>
>
>
> That would be a great improvement.
>
>
> However, wouldn't it be better to add this kind of check in a larger
>
> test framework, as discussed some weeks ago?
>
>
> Regards,
>
>
> Gaëtan
>
>
> _______________________________________________
>
> Powered by www.kitware.com
>
>
> Visit other Kitware open-source projects at
>
> http://www.kitware.com/opensource/opensource.html
>
>
> Please keep messages on-topic and check the ITK FAQ at:
>
> http://www.itk.org/Wiki/ITK_FAQ
>
>
> Follow this link to subscribe/unsubscribe:
>
> http://www.itk.org/mailman/listinfo/insight-developers
>
>
>
>
> --
>
> Stephen R. Aylward, Ph.D.
>
> Chief Medical Scientist
>
> Kitware, Inc. - North Carolina Office
>
> http://www.kitware.com
>
> (518) 371-3971 x300
>
>
>
>
> --
>
> Stephen R. Aylward, Ph.D.
>
> Chief Medical Scientist
>
> Kitware, Inc. - North Carolina Office
>
> http://www.kitware.com
>
> (518) 371-3971 x300
>
> <ATT00001.txt>
>
>
> ========================================================
>
>
> Bradley Lowekamp
>
>
> Lockheed Martin Contractor for
>
>
> Office of High Performance Computing and Communications
>
>
> National Library of Medicine
>
>
> blowekamp at mail.nih.gov
>
>
>
> _______________________________________________
>
> Powered by www.kitware.com
>
>
> Visit other Kitware open-source projects at
>
> http://www.kitware.com/opensource/opensource.html
>
>
> Please keep messages on-topic and check the ITK FAQ at:
>
> http://www.itk.org/Wiki/ITK_FAQ
>
>
> Follow this link to subscribe/unsubscribe:
>
> http://www.itk.org/mailman/listinfo/insight-developers
>
>
>
>
> ========================================================
>
> Bradley Lowekamp
>
> Lockheed Martin Contractor for
>
> Office of High Performance Computing and Communications
>
> National Library of Medicine
>
> blowekamp at mail.nih.gov
>
>
>


-- 
Stephen R. Aylward, Ph.D.
Chief Medical Scientist
Kitware, Inc. - North Carolina Office
http://www.kitware.com
(518) 371-3971 x300
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090212/ef968e51/attachment.htm>