Silvio,
I'm still not sure that it is clear to me:
-- Are you going to specify on the first command line just test items to be enabled without specifying the test project?
P.S. It looks like we had something like you want to implement in one of our projects: we had a parent 'wrapping' comand file that called several child ones. It was possible to pass to the parent file the full path to the test project file and a list of test items to be executed (if the list was empty this meant that all test items should be executed). The first child called by the parent was command file that reverted all local changes made to the test sources (this is to ensure no merging problems) and updated test sources to their latest version. Then the .js script was called that set the state of test items as required via direct modification of the test project file (see code snippet above). And, finally, the last command file triggered TestExecute that used already prepared test project file.
Hi Alex,
well my goal is, with the first TextExecute call, to prepare the test items for the second call (i.e. enable/disable a subset according to a parameter I may providevia external file that the vbs will be able to read data from).
I'll give you an example:
suppose I have a test suite (mySuite.pjs) with a project (call it myTestProject.mds) having two test groups:
NOREGRESSION_TESTS, with 12 test items
and
PERFORMANCES_TESTS, with 8 test items.
Then I write a vbs (name it testsetup.vbs with a routine called "prepareTests") placed inside the myTest.mds project, that is able to enable all the NOREGRESSION_TESTS or PERFORMANCES_TESTS according to a parameter.
My first call to TestExecute could be (supposing I wrote onto a parameter.txt file the word NOREGRESSION_TESTS) :
TestExecute.exe "C:\Work\SmartBear\TestExecute\Projects\mySuite.pjs" /r /exit /p:myTestProject /u:testsetup /rt:prepareTests
My second call would be:
"C:\Work\SmartBear\TestExecute\Projects\mySuite.pjs" /r /exit /p:myTestProject
The prepareTest sub would read from the parameter.txt file the group of tests that must be enabled and do that accordingly. Exiting I expect that those setting would be saved (as in Testcomplete) so the second call would get those tests enabled and execute them.
I hope I was clear on this!
It's a bit tricky and in order to do this you need external files describing the tree of test items (for me just simply the two groups but sometimes I guess I would need to be more deeply specific with that enabled list).
What I wanted to avoid was just that step, that's why I wante to read all the test items via COM (of course using a hidden TestComplete instance, which performs all the COM requests) with a C# form application, let the user via a UI choose what to set/unset, save the project and close all, leaving to the TestExecute command line (just the second one) the test execution.
