Forum Discussion
Hello Alex,
first of all thank you for your reply.
I will try then to parse the xml file using that code you suggested.
I had another idea I want to share with you:
1. suppose I create a vbs script inside TC that can get the test items collection, enable/disable them according to a provided parameter and that's it.
2. I then could run TextExecute with that routine to setup the test items accordingly and then
3. run Testexecute with the entire project, expecting to run just the test items selected by the point 2.
How do you see this?
If that works, it could be easier to maintain because it would be inside TestComplite IDE as the tests themselves.
Thanks in advance,
Silvio
Hi Silvio,
I am not sure that I got your idea with point #1...
If you are inside TestComplete, then just set state of test items as required, save the project and open it with TestExecute.
If you execute script that changes state of test items while the project is opened in TestComplete, then you should get a warning from TC that project file was changed and whether or not you like to reload it. If you reload, then you will have to save it and again, I don't see the purpose of opening project in TC. If you choose not to reload, then you must be very careful to not save project occasionally, because if you save the project in TC, this will overwrite changes made by the script.
Did I miss something in your idea?
- scambias6 years agoContributor
Hello Alex,
well my plan is to have a msdos batch file containing two TestExecute command line statements:
- the first one command line where I specifically run that vbs script routine to set-up all the testitems I want to run
- whereas the second TestExecute command specifies the project containing the test items.
I guess it should be possible, when exiting testExecute, that the modifications are saved into the xml project file so the second run will find that ready to be used.
- AlexKaras6 years agoChampion Level 3
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.
- scambias6 years agoContributor
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.
Related Content
Recent Discussions
- 5 hours agoSvetaG