[Insight-developers] compiling tests, include problems

Wed, 25 Jul 2001 07:50:53 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11500.0EC2B830
Content-Type: text/plain;
	charset="iso-8859-1"

The issue is "including" vs "linking against" and properly setting up the dependencies.

As it stands now:

BasicFilters depends on Common
Algorithms depends on BasicFilters and Common

Currently the testing mirrors the code tree and has similar dependencies.

Now, we could make the dependencies in the testing tree be anything we want.  And perhaps that is
what makes sense. And perhaps the directories in Testing should have completely different names than
the directories in Code.

Afterall, when you put in your "true" test of the BloxImage, it is just testing your Blox code? Or is
it also testing readers/writers, the gaussian filter, etc.

Now you could construct a Blox test that was real that didn't use some of these other classes.  For
instance, if need gaussian blurred data, you could use an input dataset that was already blurred.
Thus, your test wouldn't test the blurring code and would focus on testing your algorithm.

Pretty much every test has a "target" that it is trying to exercise but ends up testing a lot of
other code.  The beauty of the testing is that we should pick up any changes made to the target
section of the code or any of the secondary components.  But if the test is too complicated and uses
too much of the system, then it is hard to determine what causes a failure.

In the short term, however, you need to move the Blox tests that depend on elements of BasicFilters
into BasicFilters.  Once we tag the alpha, we can readdress this.

-----Original Message-----
From: Damion Shelton [ mailto:dmsst59+@pitt.edu <mailto:dmsst59+@pitt.edu> ]
Sent: Tuesday, July 24, 2001 7:02 PM
To: Miller, James V (CRD); Insight-developers (E-mail)
Subject: Re: [Insight-developers] compiling tests, include problems

Ok... so maybe the solution is to allow tests in any directory to include
files from any and all of the allowable ITK include paths. I think this
actually makes sense, because as the toolkit evolves, there are bound to be
tests of other classes that need to include files from multiple directories
(basicfilters, common, statistics, etc.) in order to do a meaningful.

For instance, it is certainly possible to write a test that exercises blox
objects without relying on basicfilters files, but this test wouldn't be
much of a true test; in order to perform one, I need a source of data via
spatial functions (from common) and a way to perform blurring and edge
detection (from basicfilters).

Is there a compelling reason _not_ to allow tests to include any ITK file
they want to?

-Damion-

> Careful...  I think the test may have to be in BasicFilters but I don't
> want to get in a mode of transferring files from Common to BasicFilters
> just so that we can test them.

------_=_NextPart_001_01C11500.0EC2B830
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE></TITLE>

<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY>
The issue is "including" vs "linking against" and properly 
setting up the dependencies. As it stands now: BasicFilters 
depends on Common Algorithms depends on BasicFilters and 
Common Currently the testing mirrors the code tree and has similar 
dependencies. Now, we could make the dependencies in the testing tree be 
anything we want.&nbsp; And perhaps that is what makes sense. And perhaps the 
directories in Testing should have completely different names than the 
directories in Code. Afterall, when you put in your "true" test of the 
BloxImage, it is just testing your Blox code? Or is it also testing 
readers/writers, the gaussian filter, etc. Now you could construct a Blox 
test that was real that didn't use some of these other classes.&nbsp; For 
instance, if need gaussian blurred data, you could use an input dataset that was 
already blurred.&nbsp; Thus, your test wouldn't test the blurring code and would 
focus on testing your algorithm. Pretty much&nbsp;every test has a 
"target" that it is trying to exercise but ends up testing a lot of other 
code.&nbsp; The beauty of the testing is that we should pick up any changes made 
to the target section of the code or any of the secondary components.&nbsp; But 
if the test is too complicated and uses too much of the system, then it is hard 
to determine what causes a failure. 
In the short term, however, you need to move 
the Blox tests that depend on elements of BasicFilters into BasicFilters.&nbsp; 
Once we tag the alpha, we can readdress this. -----Original 
Message----- From: Damion Shelton [<A 
href="mailto:dmsst59+@pitt.edu">mailto:dmsst59+@pitt.edu</A>] Sent: Tuesday, 
July 24, 2001 7:02 PM To: Miller, James V (CRD); Insight-developers 
(E-mail) Subject: Re: [Insight-developers] compiling tests, include 
problems Ok... so maybe the solution is to allow tests in any 
directory to include files from any and all of the allowable ITK include 
paths. I think this actually makes sense, because as the toolkit evolves, 
there are bound to be tests of other classes that need to include files from 
multiple directories (basicfilters, common, statistics, etc.) in order to do 
a meaningful. For instance, it is certainly possible to write a test that 
exercises blox objects without relying on basicfilters files, but this test 
wouldn't be much of a true test; in order to perform one, I need a source of 
data via spatial functions (from common) and a way to perform blurring and 
edge detection (from basicfilters). Is there a compelling reason _not_ 
to allow tests to include any ITK file they want 
to? -Damion- &gt; Careful...&nbsp; I think the test may have to be 
in BasicFilters but I don't &gt; want to get in a mode of transferring files 
from Common to BasicFilters &gt; just so that we can test 
them. </BODY></HTML>

------_=_NextPart_001_01C11500.0EC2B830--