David Corley (AT/LMI) wrote:
I should explain my reasoning for carrying things out the way I do.
Basically, I've defined a core build.xml for every developer on our
site. It allows them to only have to set their classpaths and
properties, and everything else will just work for them. So far it's
been quite succesful. But we came across a stumbling block where some
developers wanted to run tests against code they had just compiled.
Normally the developers would have stubs for their unit tests, but some
developers need to run against a live server. And the server code may
have just been compiled as part of the build.
Unfortunately the core build doesn't facilitate the running of any
compiled code, aside from the unit tests, which are run with the ant
<junit> task.
OK
So I came up with a workaround, where I allow the developers to do what
they like right before the unit testing starts and straight after it
finishes.
It means the core build.xml is still untampered, and the used get to run
whatever <java> tasks need to be run before testing with their custom
junit-setup.xml targets. I suppose I could use <import>....but why
should I have to? The <ant> task should work just fine... No?
<ant> does create a new project, and doesnt return state to the system,
so its not ideal.
I sometimes use import for this, but let people override the junit
target itself, with different test patterns. We also have a custom task,
<functionaltest> which integrates setup, parallel deployment, a spin
until the system is running and cleanup
<sf-functionaltest testTimeout="600" shutdownTime="10">
<application>
<sf-startdaemon-debug failonerror="false" spawn="false"/>
</application>
<probe>
<socket port="${smartfrog.daemon.port}" server="localhost"/>
</probe>
<test>
<sf-junit
fork="true"
includeantruntime="true"
haltonfailure="true"
>
<classpath
refid="tests.run.classpath"/>
<batchtest todir="${test.data.dir}">
<fileset dir="${test.classes.dir}">
<include name="**/unit/*Test.class"/>
<include name="**/system/**/*Test.class"/>
</fileset>
</batchtest>
</sf-junit>
</test>
<teardown>
<sf-stopdaemon failonerror="false"/>
<sf-junitreport data="${test.data.dir}"
reports="${test.reports.dir}"
/>
</teardown>
</sf-functionaltest>
Notice how we dont even need to tell junit not to fail if the tests
fail, because the teardown sequence generates the junit report and then
re throws the junit-initiated failure method, if that is how junit ended.
The LGPL source is available for this if you want it.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
