It looks like that the test executor see that there are differents test suites (Running Test Suite: TestSuite1 (1/2) but after executing the firt test suite, the testexecutor stop the AUT and never run TestSuite2 ...
Does I miss something ?
I prefer not to use test Job because I have to specify the AUT for each test suite and I have 4 AUT on 3 system (win32, win64 and mac) to test ... Using test suite, it's easy because I only have to do some copy/paste in the configuration file ...
it is not possible to run different Test Suites with only one run of the test executor. So if you don´t want to use Test Jobs you will have to use a separate run of the test executor for each Test Suite.
Well, in this case, I think the only think to do is to use TestJob. Even If I have to do 3 times the same things ... It will not be easy to maintain this (the test are the same for win32,win64 and mac version) but the test suite is per AUT ID...
We have 4 versions of our <Program>. Each one have the same base (so I only created 1 AUT) but some test are version specific. For example, you have to do steps before running the 'core' test who is available for each version...
So I defined 12 AUT configuration :
This way, the test suite are for <Program> and I can specify everything in the XML config file for testexecutor.
The solution is to transform my testsuite into test case and this way, I will only have 4 test suite (one for each version) and I only have to run one test suite per system.
I don't really see what's the interest of Test Jobs ... May I miss something ?
Why does the configuration file include the <entry> tags for testsuite if only one testsuite can be executed per invocation of testexec? Is this functionality something that will be extended in the near future?
If i would be able to specify multiple TestJobs in the Config File and I check the Config File to the source code.
I would have had a easy overview labeld with the source code which tests are executed.
e.g. we a running continour builds -> Many Builds -> Many Labels -> which testcase was executed with this Build
I would have to create thousands of Jubula Project versions now, which i dislike, as we would have created a new Jubula Version only on a Release Build.
Now we have no possibilty to see in the continous build phase which test cases where executed.
If you did decide to execute single Test Suites with the current setup, then you would need separate config files for the test exec for each Test Suite (I'm fairly sure the config files could be parametrized so you only actually have to enter the Test Suite names you want to be executed). The problem with executing single Test Suites (even if multiple entries were allowed) is that you have to add each name to your test exec to make it be executed - there's more on background on this in this thread.
You could also decide to use Test Jobs (which are made up of individual Test Suites) and perform queries on the test result table in the database to see which individual Test Suites were executed.