Forum Discussion
Hi Silvio,
I am far not sure if it is possible to modify state of test items via TestComplete COM if test project is opened in TestComplete.
What I did, was to enable all/required test items via direct modification of the project file with the help of standalone .js script and then open project in TestComplete.
Note 1: Provided code sample worked in TC 12.
Note 2: Obviously, the same code might not work in subsequent versions of TC.
var oXml = GetDefaultXMLObj(); var xmlDoc = loadXML(oXml, projectFile); //WScript.Echo("Test Items : '" + testItems + "'"); if ("" == testItems) { testItemXPath = "//*/testItems/children//testItem"; testItems = xmlDoc.selectNodes(testItemXPath); for (testItemIdx = 0; testItemIdx < testItems.length; testItemIdx++) { element = testItems[testItemIdx]; if (null != element) { if ("False" == element.getAttribute("enabled")) { element.setAttribute("enabled", "True"); // WScript.Echo("'" + element.getAttribute("name") + "' test item was enabled"); } } } WScript.Echo("All test items for the project were enabled"); } else { testItems = testItems.split('~'); for (testItemIdx in testItems) { testItem = testItems[testItemIdx]; //WScript.Echo(testItem); testItemXPath = "//*/testItems/children//testItem[@name='" + testItem + "']"; element = xmlDoc.selectSingleNode(testItemXPath); if (null != element) { if ("False" == element.getAttribute("enabled")) { element.setAttribute("enabled", "True"); WScript.Echo("'" + testItem + "' test item was enabled"); } } else WScript.Echo("'" + testItem + "' test item was not found"); } } xmlDoc.save(projectFile);
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
- AlexKaras6 years agoChampion Level 3
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.