-
1. Re: Tests that require shutdown of JBoss
starksm64 Jan 10, 2006 4:20 PM (in response to anil.saldhana)One way would be to have a notion of user supplied shutdown hooks that ran before/after the jboss hooks. These could be dynamically inserted by the shutdown unit test setup and this test would be run as part of the server shutdown task itself.
The big detail is how to get the results from the components that have shutdown behaviors back to the unit tests. I think it would require a custom socket connection with the results written back to the unit test as part of the post jboss shutdown hook installed by the unit test. -
2. Re: Tests that require shutdown of JBoss
ryan.campbell Jan 10, 2006 5:09 PM (in response to anil.saldhana)In the existing tests, the JUnit process is dead and gone by the time server shutdown occurs, so it seems this is one more requirement for a custom TestRunner which starts & stops jboss instances while maintaining test state .
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=60307 -
3. Re: Tests that require shutdown of JBoss
anil.saldhana Jan 10, 2006 5:19 PM (in response to anil.saldhana)The way, I wrote the testcase for the tomcat issue is that whenever the contextDestroyed on the context listener is called on the context shutdown, it creates a file in the jboss temp directory. Now in my testcase, I do a jmx shutdown, wait for 20secs and just check if the temp file is created. If it is there, test passes (because the contextDestroyed was called). At the end of the test, clear the text file.
This was a simple solution for me. But the issue is, this is one test behavior.
Another simple approach:<target name="jboss-all-config-tests" description="The units tests which are run against the jboss all config"> <server:start name="all"/> <!-- It requires -Dmatrix-versions=defined if you want to execute this task. More information at http://wiki.jboss.org/wiki/Wiki.jsp?page=HowToExecut eMatrixTests --> <antcall target="tests-standard-unit-matrix"/> <antcall target="tests-standard-unit"/> <antcall target="tests-client-unit"/> <antcall target="tests-security-basic-unit"/> <antcall target="tests-standard-stress"/> <antcall target="tests-jbossmx-compliance"/> <antcall target="tests-jbossmx-implementation"/> <antcall target="tests-jbossmx-performance"/> <antcall target="tests-iiop"/> <antcall target="tests-scout-jaxr"/> <antcall target="tests-webservice"/> <antcall target="tests-txtimer"/> <antcall target="prepare-deployments"/> <server:stop name="all"/> <antcall target="collect-assertions"/> </target>
"prepare-deployments"(any other name) will basically have one testcase that deploys all the archives that have test deployments/hooks into the running instance. Now after the server has stopped cleanly, the "collect-assertions" (or any other name) runs a set of tests that basically look for the results like in a file with strict string match.
The issue I see is getting the results back to the unit tests. Having shutdown hooks and a custom socket to derive the results may be an appropriate solution, but it looks complicated. -
4. Re: Tests that require shutdown of JBoss
starksm64 Jan 10, 2006 5:58 PM (in response to anil.saldhana)Having to look for files breaks the ability to run the tests against a remote host. Pushing serialized objects back through a socket connection is not much more coding than writing a file.
-
5. Re: Tests that require shutdown of JBoss
starksm64 Jan 10, 2006 6:00 PM (in response to anil.saldhana)"ryan.campbell@jboss.com" wrote:
In the existing tests, the JUnit process is dead and gone by the time server shutdown occurs, so it seems this is one more requirement for a custom TestRunner which starts & stops jboss instances while maintaining test state .
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=60307
Yes, this capability should just be part of the tests core. -
6. Re: Tests that require shutdown of JBoss
anil.saldhana Jan 11, 2006 1:47 AM (in response to anil.saldhana)"scott.stark@jboss.org" wrote:
Having to look for files breaks the ability to run the tests against a remote host. Pushing serialized objects back through a socket connection is not much more coding than writing a file.
I did not realize that the tests may have to be performed against a remote host. My approach does not work in this scenario.