On 1/24/07, Steve Loughran <[EMAIL PROTECTED]> wrote:
Xavier Hanin wrote:
>
> I'm not sure the online tests should be part of gump. Actually, I often
> think that online tests should be replaced by more reliable tests,
because
> most of the time they fail only because the online resource is not
> available
> (we have tests relying on ibiblio for instance, and they often fail with
> timeouts). Moreover they are very slow compare to other tests, so
running
> them is tedious. So I don't know if we should get rid of those tests, or
> rewrite them using jetty for instance for http tests... I'm not familiar
> with this kind of tests which start a web server, that's why I never
took
> time to rewrite the tests. But if somebody can help, it would be really
> nice.
>
aah, you've just jumped from unit tests to functional/system tests at
this point.
welcome to complexity.
1. yes, smartfrog can do this kind of thing, but I tend to avoid running
them under gump. I am having enough problems getting everythign to build
right now.
2. apache cactus has an ant task that brings up an app server, runs the
tests and tears down the server afterwards. Use it ahead of trying to
do the same thing in your test code
3. smartfrog-tasks (under gump) provides a <functionaltest> task that
goes beyond <cactus> to start and stop anything. The <application>
sequence runs, then <probe> condition starts probing for visible state;
once that condition passes the test sequence runs. whether the tests
pass or not, a <finally> sequence kicks in to do cleanup. There's lots
of timeout support in case something hangs too:
<target name="system-tests" depends="ready-to-system-test" >
<sf:functionaltest testTimeout="600" shutdownTime="10">
<application>
<sf:daemon-debug failonerror="false" spawn="false"
classpathref="tests.run.classpath"/>
</application>
<probe>
<socket port="${smartfrog.daemon.port}" server="localhost"/>
</probe>
<test>
<core:junit
errorProperty="test.failed"
failureProperty="test.failed"
includeAntRuntime="true"
>
<classpath>
<path refid="tests.run.classpath"/>
</classpath>
<batchtest todir="${test.data.dir}">
<!-- bulk test case -->
<fileset dir="${test.classes.dir}">
<include name="org/smartfrog/**/system/**/*Test.class"/>
</fileset>
</batchtest>
</core:junit>
<fail if="failure">Junit failed</fail>
</test>
<teardown>
<sf:stopdaemon failonerror="false"/>
</teardown>
</sf:functionaltest>
</target>
Interesting, thanks for your help. Cactus seems to have something pretty
simple to setup:
http://jakarta.apache.org/cactus/integration/integration_jetty.html
Since in our case what we want to test is not the server side, but only the
client side, it seems to be enough for our needs. Another advantage I see is
that you can run your unit test from the IDE easily (I mean, without
invoking ant, directly from the junit view). But maybe it's also the case
with smartfrog?
Xavier
-steve
