views:

52

answers:

2

The build.xml we have today have many targets to compile and run unit tests. The build.xml refers to many property files with relative to itself. All this works fine when build and test is done on same machine.

It is pretty simple to do build get all jars and any test input files to a build_home(another machine). How to run junit on the new location? Should I create small build.xml files to running the tests? (There is no way to create ant build.xml dynamically) Any solutions?

( GridGain is possible solution. Not tried yet. )

Edit: Mode details on why this more complicated: The source code is around 3G, doing clearcase update and build takes considerable time (40 minute) against real test time of junit testing - 60 minutes. We have many machines to run the tests -- loading Clearcase on all systems not possible.

+1  A: 

Try Cruise Control. It's a great way to offload your build and unit test to another machine.

duffymo
Thanks. How does cruise control run the tests? we use hudson, so I could use similar technique.
Jayan
Hudwon works equally well. Why not configure it to run your tests as part of your build?
duffymo
We do that. It works fine. The difference is doing the build on hudson, running the tests on another. The way I see now is to have the junit run code in another ant file say junit.xml, copy over along with "jars" and "testdata". Run tests using junit.xml ( from JoseK )
Jayan
+2  A: 

I understand your question as you want to only run the Junit tests on another machine without actually building on it? You can run something on the lines below as build scripts from Cruise control and probably Hudson too

If you're using the task via ant, then follow the same principles as a standard build. You can check out the code to all target machines from source control.

Externalize all root directories to a build.properties. These are properties which have to be set on each machine like so.

#Overall Project Name
project.name=myapp

# Top Level Root directory of the new working project
toplevel.project.dir=D:/proj/eComm

# Root directory of the source code
root.project.dir=D:/proj/eComm/Construction

# JDK home directory 
jdk.home=C:/jdk1.5.0_11

build.properties will also have some static properties defined relative to the above. These need not be changed by any user on any local machine.

ear.dist.dir = ${root.project.dir}/target
src.dir     = ${root.project.dir}/src
test.src.dir = ${root.project.dir}/test

Ensure your build.xml only refers to any further sub directories via these properties without any hardcoded values in it.

My junit are in a separate file which is imported into the build.xml by

<import file="${root.project.dir.buildscripts.dir}/junit.xml"/>

and some part of junit.xml is shown below

<target name="run.junit" depends="clean.junit, junit.info, prepare.junit"
    description="Compiles and runs all JUnit Tests in the 'test' directory and produces a report of all failures">

<junit printsummary="yes" fork="true" haltonfailure="no" showoutput="yes" maxmemory="512m">
      <jvmarg line="${junit.jvm.arg}"/>
      <classpath>
        <fileset dir="${src.dir}">
          <include name="**/*.*"/>
        </fileset>
        <fileset dir="${ear.dist.dir}/build/classes">
          <include name="**/*.*"/>
        </fileset>
         <pathelement path="${test.run.path}"/>
      </classpath>
      <formatter type="xml"/>
      <batchtest fork="true" todir="${ear.dist.dir}/build/junit">
      <fileset dir="${test.src.dir}" includes="${test.pattern.include}"/>
      </batchtest>
    </junit>

</target>
JoseK
You almost said what I want is not possible with out changes in build.xmls. Accepted answer as it has enough explanation about how to structure the build files. Thanks!
Jayan