another unit-test question

[Erik Price <ep...@ptc.com>]

I have one other question (where I am uncertain of the "best practice"). 
  Following along in "Java Development with Ant", in the context of 
using JUnit for unit testing.

It is recommended to keep test code separate from production code in the 
filesystem, using unique directory trees.  This makes sense, because you 
want to be able to easily copy or access your production code without 
filtering through files ending with "*Test.java".  But if you don't put 
the test code in with the production code, how can they share the same 
package?  It seems to be recommended that unit tests share the same 
package as the code that they are testing (this is also evident in the 
example in the book, in which "HtmlDocumentTest" [a unit test] is 
declared to be in the same package as the production code).

Should I be copying my production code source tree into a new tree with 
the test code embedded alongside it?  If so then what happens when I 
make a change to the source code, I have to first copy it into the test 
tree so that I can run the unit tests again?

Sorry, it's a little confusing to me.


Erik

Re: another unit-test question

[Andrew Forward <mi...@hotmail.com>]

First off, although packages look like directories, they are not.... So
having separate directories for source code (i.e. the test code, real code,
maybe even gui code) does not effect the package structure of your code.

> how can they share the same package?

tell ant to look in /src/main and /src/testsuite for source code when
testing

use the 'src' element like
  <src path="${src.main}"/>
  <src path="${src.testsuite}"/>

In essence when you are doing testing, you tell ant to look in more than one
place for .java files.  So if these two places both have a ca.app package
then it's as if the physical files where located in the same directory.


> Should I be copying my production code source tree into a new tree with
the test code embedded alongside it?

No.

Re: another unit-test question

[Erik Hatcher <ja...@ehatchersolutions.com>]

On Tuesday, March 4, 2003, at 07:42  PM, Erik Price wrote:
> Great.  ${ant.home} was exactly what I needed.  (Actually, it didn't 
> work at first, and I wondered if I had done something wrong but my 
> build file seemed to be right.  It turns out that junit.jar doesn't 
> work if it's a symlink [at least on Cygwin], but when I copied the JAR 
> into ANT_HOME it worked great.  Strangely, xalan.jar [for generating 
> reports per the <junitreport> task] works fine as a symlink into 
> ANT_HOME.)

I'm guessing you mean ANT_HOME/lib rather than just ANT_HOME here.  
Only the lib subdirectory is part of the operating classpath, not the 
root directory (just in case that was the issue you had).

> I hadn't thought of that.  It seems that a lot of the constraints that 
> I took for granted (specifically keeping files together, etc) are 
> lifted when you explicitly declare classpaths via ant etc.  My 
> interpretation of what you are saying is that when you run your unit 
> tests, it is as if you were doing a standard "compile" target (your 
> production code goes where it's supposed to), and the unit-test .class 
> files go into the "test" directory -- and that they never need to be 
> brought into the same directory because ant can "see" the unit-test 
> code and the production code even when they are in different dirs.

Actually its not even a constraint at the command-line without Ant.  
Its a class *path* and can be a series of directories.  So its always 
been ok to separate test and production source and .class files.  Ant 
makes dealing with classpaths a lot easier, and is one of the nicest 
things about using Ant, in fact.

	Erik

Re: another unit-test question

[Erik Price <ep...@ptc.com>]

Erik Hatcher wrote:

> junit.jar=${ant.home}/lib/junit.jar
> 
> in a lib.properties file that gets loaded by the main build file.
> ${ant.home} is automatically set by Ant.

Great.  ${ant.home} was exactly what I needed.  (Actually, it didn't 
work at first, and I wondered if I had done something wrong but my build 
file seemed to be right.  It turns out that junit.jar doesn't work if 
it's a symlink [at least on Cygwin], but when I copied the JAR into 
ANT_HOME it worked great.  Strangely, xalan.jar [for generating reports 
per the <junitreport> task] works fine as a symlink into ANT_HOME.)

> To help answer both your e-mails, please download the JavaDevWithAnt
 > project I've created based on the project Steve and I created for the 
book.

I will definitely check it out.  It is great to have feedback from the 
very people who wrote the book.


later, Erik Hatcher wrote:
> Just to add my $0.02 on this... I don't compile the production and test 
> code together into a single tree.  I keep them separate even for the 
> .class files.  Because of Ant's nice <path> handling, its easy to put 
> them together when you need them together (in <junit> for example).

I hadn't thought of that.  It seems that a lot of the constraints that I 
took for granted (specifically keeping files together, etc) are lifted 
when you explicitly declare classpaths via ant etc.  My interpretation 
of what you are saying is that when you run your unit tests, it is as if 
you were doing a standard "compile" target (your production code goes 
where it's supposed to), and the unit-test .class files go into the 
"test" directory -- and that they never need to be brought into the same 
directory because ant can "see" the unit-test code and the production 
code even when they are in different dirs.

Thanks, I'll adjust my build file to reflect this strategy as it does 
make good sense.


Erik

Re: another unit-test question

[Erik Hatcher <ja...@ehatchersolutions.com>]

Just to add my $0.02 on this... I don't compile the production and test 
code together into a single tree.  I keep them separate even for the 
.class files.  Because of Ant's nice <path> handling, its easy to put 
them together when you need them together (in <junit> for example).

The only time I blur test code together with production code is with 
Cactus tests that have to be deployed into the container.

	Erik

On Tuesday, March 4, 2003, at 06:28  PM, Erik Price wrote:
>
>
> Erik Price wrote:
>> Should I be copying my production code source tree into a new tree 
>> with the test code embedded alongside it?  If so then what happens 
>> when I make a change to the source code, I have to first copy it into 
>> the test tree so that I can run the unit tests again?
>
> Nevermind, it just clicked.  I keep the test code in one tree, and the 
> production code in another tree (so they are not mingled together), 
> but in my "test" target I can use the "javac" task on both trees and 
> compile them together into a single tree of unit-testable code, and 
> run unit tests on that...
>
> /project
>   /src
>     /com
>       /erikprice
>         /myproj
>           productioncode.java
>   /test
>     /com
>       /erikprice
>         /myproj
>           unittestcode.java
>   /build
>     /test
>       /com
>         /erikprice
>           /myproj
>             productioncode.class
>             unittestcode.class
>
> ...confirmed by Matt Quail as I finished up this email.  Thanks and 
> pardon me for not having seen this in the first place ;) !
>
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>

Re: another unit-test question

[Erik Price <ep...@ptc.com>]

Erik Price wrote:
> Should I be copying my production code source tree into a new tree with 
> the test code embedded alongside it?  If so then what happens when I 
> make a change to the source code, I have to first copy it into the test 
> tree so that I can run the unit tests again?

Nevermind, it just clicked.  I keep the test code in one tree, and the 
production code in another tree (so they are not mingled together), but 
in my "test" target I can use the "javac" task on both trees and compile 
them together into a single tree of unit-testable code, and run unit 
tests on that...

/project
   /src
     /com
       /erikprice
         /myproj
           productioncode.java
   /test
     /com
       /erikprice
         /myproj
           unittestcode.java
   /build
     /test
       /com
         /erikprice
           /myproj
             productioncode.class
             unittestcode.class

...confirmed by Matt Quail as I finished up this email.  Thanks and 
pardon me for not having seen this in the first place ;) !


Erik

Re: another unit-test question

[Matt Quail <ma...@cortexebusiness.com.au>]

Erik,

It is perfectly acceptable and legal (and desirable) to have the same package 
under two different source trees. So you may have a Foo.java and a FooTest.java 
in package "com.bar"; but you can have them in two different directory structures:

./source/com/bar/Foo.java
./tests/com/bar/FooTest.java

When you compile them, you can compile them to different directories:
./build/classes/com/bar/Foo.class
./build/test-classes/com/bar/FooTest.class

or to the same directory, if you wanted:
./build/classes/com/bar/Foo.class
./build/classes/com/bar/FooTest.class

=Matt

Erik Price wrote:
> I have one other question (where I am uncertain of the "best practice"). 
>  Following along in "Java Development with Ant", in the context of using 
> JUnit for unit testing.
> 
> It is recommended to keep test code separate from production code in the 
> filesystem, using unique directory trees.  This makes sense, because you 
> want to be able to easily copy or access your production code without 
> filtering through files ending with "*Test.java".  But if you don't put 
> the test code in with the production code, how can they share the same 
> package?  It seems to be recommended that unit tests share the same 
> package as the code that they are testing (this is also evident in the 
> example in the book, in which "HtmlDocumentTest" [a unit test] is 
> declared to be in the same package as the production code).
> 
> Should I be copying my production code source tree into a new tree with 
> the test code embedded alongside it?  If so then what happens when I 
> make a change to the source code, I have to first copy it into the test 
> tree so that I can run the unit tests again?
> 
> Sorry, it's a little confusing to me.
> 
> 
> Erik
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
> 
> 
>