after updating (from https://svn.jboss.org/repos/jbossas/trunk), i ran
$ ./build.sh jboss-all-config-tests
and ENCUnitTestCase was successfull ,but as i wrote in jira (sorry for the discuccion on jira and not this forum, i'm stll learning :) ), deploying queues/topics at the startup of the server cause other tests to fail (one of them is org.jboss.test.cts.test.BmpUnitTestCase) becasue they can't deploy their own queues/topics ,because some of them (queue/A, queue/C) are already deployed (at the startup).
Anill suggests, that everything(common resources like queues A,B,C...) should be deployed during the start of the "all" instance, so the tests don't have to care what they have to deploy at the beginning. in this case some tests must be reconfigured, to not start queues/topics at their start.
But this strategy is not perfect. What about single tests? Do I have to deploy jbossmq-destinations-service.xml every time I start a single test?
The answer lies in checking that the failing tests (incl BmpUnitTestCase) and their resources are in sync with Branch_4_0.
I am guessing they are not. If not, they can be reverted to be in sync.
I understand, that the strategy for running the testsuite is to deploy common resources (queues/topics) during the startup of the AS. This needs to revert some tests so they don't deploy duplicated resources. no problem.
But what about single tests?
./build.sh one-test -Dtest=org.jboss.test.cts.test.BmpUnitTestCase
For this test I have to start the AS manually, and when I don't deploy jbossmq-destinations-service.xml (all needed queues), the test will fail.
I guess we can circumvent by making the copy of the temp destinations also part of the target "one-test", because the ant copy task can do a copy only, if the resource does not exist.
But the issue that is uncertain is will be the running jboss instance be the "all" config instance. We cannot make that assumption.
This is getting convoluted.
"But the issue that is uncertain is will be the running jboss instance be the "all" config instance. We cannot make that assumption. "
That's the reason why every test should provide its own resources, like severel tests already do. They deploy jar files which describe, which queues and topics are needed during the test. But Anil, you said, that this would cost a lot of time to rewrite the rest of the tests to do so.
On the other hand, we can say, that the most tests needs the "all" config (which would bound all needed queues/topics at the startup) and revert these few tests, so they will not deploy the needed resources. I can try to do this.
So my question is, what is the strategy for the testsuite? Reverting some tests and say, that most tests require the "all" instance OR changing the conception of the most tests, so that every test has to provide its own resources, that means deploying them on the start of the test and undeploying them on the end. But wouldn't this increase the time of running the testsuite, when every test will deploy its own resources?
Only a handful of tests depend on the temporary destinations. So choices are:
a) Retrofit all the tests (in the 3 branches) to deploy their own local resources (This is the ideal situation). But the effort involved is not worth it at the moment.
b) Copy the destination-service.xml as part of the "one-test" target and put an echo message at the end, stating that if the test failed, try with all config as the running instance. Remember "one-test" is just a shortcut target (so not high priority).
IMHO we should keep the tests(resources including) consistent across branches. There may be others who have different opinion.
Agreed, things need to be consistent across all branches.
If you have the time, do option a). Ideal situation in the long run.
There is another issue also. When JBoss Messaging becomes the default over JBoss MQ. The destination mbean will also change. So if each test in HEAD testsuite deploys its own destinations, then the mbean defs have to change.
In this case, the option b) is good because it is just one xml file to update.