Tests that require shutdown of JBoss

[anil.saldhana]

Here is an old bug that exists in our JIRA:
http://jira.jboss.com/jira/browse/JBAS-850

Basically, any test to solve this issue would need to consider a JBoss instance that is shutting down.

We need some kind of a setup in our testsuite that allows us to test against an instance that is shutting down.

Possible Solutions:
a) Create seperate test configs. [Not good]
b) Have seperate ant targets with start /stop of JBoss instances. [Not good]

Here is the directive from Scott:

We should add shutdown tests that runs against the all configuration
section of tests and collects assertions from the deployments that want
to perform shutdown operations.

[starksm64]

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.

[ryan.campbell]

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

[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.

[starksm64]

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.

[starksm64]

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.

[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.

I did not realize that the tests may have to be performed against a remote host. My approach does not work in this scenario.