Forum Discussion
kirk_bottomley
11 years agoContributor
I've been trying to write the code to do this, but I keep running up against walls.
I was going to take the suggestions here and create an XML that will store the variables needed for each machine, then read those in at the start of a test.
Then I got the idea that when a workstation opens the project, as long as they open it in shared mode, there is a folder created with their workstation id already.
So...
I wanted to create a Master XML that is stored at Project.Path that has all the variable information in it. Then when a user opens the project, it checks to see if they already have a workstation.xml file in their share folder. If not, copy the Master.xml to workstation.xml at Project.ConfigPath, set the variables, then run the tests. If it exists already, just run the tests.
For variables that won't change often, I wanted to set the Category property for that variable to "Fixed". If it's something that will vary from machine to machine, like AppPath or testbed locations, I was going to set the Category to "User". Then when the XML is parsed the first time, it would pop up a form allowing the user to configure their own machine settings the first time, and never have to do it again.
The first problem I found was that NetworkSuite variables can't be created this way.
Then I found that the Category and Description properties can't be addressed this way.
Note that all of this could be simplified with an interface to change a workstation's variables. Having to write all this code to bypass that lack is frustrating enough, but it is beginning to look like even that approach has been purposefully hobbled.
Is there some exploit that people might take advantage of if they had access to configure the variables in a workstation's share folder? It looks like TestComplete goes out of its way to make variable configuration impossible.
Can anyone think of a workaround for this workaround approach to work? Or a better approach altogether?
I was going to take the suggestions here and create an XML that will store the variables needed for each machine, then read those in at the start of a test.
Then I got the idea that when a workstation opens the project, as long as they open it in shared mode, there is a folder created with their workstation id already.
So...
I wanted to create a Master XML that is stored at Project.Path that has all the variable information in it. Then when a user opens the project, it checks to see if they already have a workstation.xml file in their share folder. If not, copy the Master.xml to workstation.xml at Project.ConfigPath, set the variables, then run the tests. If it exists already, just run the tests.
For variables that won't change often, I wanted to set the Category property for that variable to "Fixed". If it's something that will vary from machine to machine, like AppPath or testbed locations, I was going to set the Category to "User". Then when the XML is parsed the first time, it would pop up a form allowing the user to configure their own machine settings the first time, and never have to do it again.
The first problem I found was that NetworkSuite variables can't be created this way.
Then I found that the Category and Description properties can't be addressed this way.
Note that all of this could be simplified with an interface to change a workstation's variables. Having to write all this code to bypass that lack is frustrating enough, but it is beginning to look like even that approach has been purposefully hobbled.
Is there some exploit that people might take advantage of if they had access to configure the variables in a workstation's share folder? It looks like TestComplete goes out of its way to make variable configuration impossible.
Can anyone think of a workaround for this workaround approach to work? Or a better approach altogether?
Related Content
Recent Discussions
Name Mapping Issue
Solved2 hours agokgreger1- 2 days agodhundley