Forum Discussion
Hi,
I like to use project and project suite variables to keep (runtime) test configuration data and to exchange dynamic data between tests (e.g. id of created account, list of ordered items, etc.)
The real advantage of project variables in the projects opened in the shared mode was that variables' values were personalized and the same variable could be used concurrently by the same test running at the same time on two different machines. Unfortunately, this great feature seems to be broken in the past versions of TestComplete and I am not sure if it is going to be fixed.
Another problem with project variables is that their values are stored in the project file not in clear text and TestExecute does not provide any means to change the value of some variable before test run. This makes it not convenient to store test configuration data just in project variables because it is not easy to set their values on the systems that have only TestExecute installed. Situation here is more clear: it was said that it is not planned to add any UI features to TestExecute to make it possible to set project variables.
- tristaanogre8 years agoEsteemed Contributor
AlexKaras wrote:
The real advantage of project variables in the projects opened in the shared mode was that variables' values were personalized and the same variable could be used concurrently by the same test running at the same time on two different machines. Unfortunately, this great feature seems to be broken in the past versions of TestComplete and I am not sure if it is going to be fixed.
Actually, doesn't that still "live" with persistent variables? It's not present for temporary variables, but persistent it is. You need to explicitly create the variable as persistent to get that localized value.
As for the inability to set variable values on TestExecute machines... yeah, not convenient, but we solved that in the past by creating an INI file that resided on each workstation that, on project startup, we would read the values in from there into the appropriate persistent variables. Worked pretty well for quite a number of years, actually. :)
These days, I don't use project or project suite level variables so much. If I need something passed between projects, usually it's something necessary for the overall framework in which I'm functioning.. and since the framework is all in ScriptExtensions, I just make my "global" variables properties on my RuntimeObjects.
- AlexKaras8 years agoChampion Level 3
Hi Robert,
> Actually, doesn't that still "live" with persistent variables?
Not sure and probably need to double-check. According to what I remember, I found this problem exactly for persistent variables (after I did not use shared mode for a year or more).
Finally, I also ended-up with some sort of INI file (actually, .csv assessed via SQL ;) ) that is used to populate project variables with data. The only difference is that for this I prefer temporary variables more because a) I do not need their values to be preserved between test runs (when this is needed, the same INI file is used); and b) When the value of persistent variable is changed, the project is marked as modified and, when using version control system, you need either explicitly discard changes or accept them. Also, when in shared mode, other users receive message that the project was changed and needs to be reloaded. This does not happen for temporary variables.
Related Content
- 10 months agojamescollett
- 3 months agoStoplight
- 5 years agoKrishna_Kumar
- 2 years agoTestQA1
Recent Discussions
- 7 hours agoMW_Didata