| "java.lang.ClassCastException: org.apache.tools.ant.types.Path " error after | "java.lang.ClassCastException: org.apache.tools.ant.types.Path " error after 2006-09-22 - By Steve Loughran
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: user-unsubscribe@(protected)
For additional commands, e-mail: user-help@(protected)
|
|
 |
