workspace_loc variable not resolved when running tst in Load Test
I have configured and verified the load test with no issues, and ran it locally without problem, however, when running through loadtest, I receive the following error:
java.text.ParseException: Variable "workspace_loc" could not be resolved at com.parasoft.util.VariableResolverUtil.resolveToObjects(VariableResolverUtil.java:160) at com.parasoft.util.VariableResolverUtil.resolveToObjects(VariableResolverUtil.java:129) at com.parasoft.util.VariableResolverUtil.resolve(VariableResolverUtil.java:75) at webtool.tool.ToolVariableResolverUtil.resolve(ToolVariableResolverUtil.java:24) at webtool.tool.ToolVariableResolverUtil.resolve(ToolVariableResolverUtil.java:17) at webtool.scripting.MethodTool.getToolUsableObject(MethodTool.java:198) at webtool.scripting.MethodTool.applyTool(MethodTool.java:235) at com.parasoft.tool.Tool.apply(Tool.java:341) at com.parasoft.tool.Tool.getApplyResult(Tool.java:353) at webtool.test.ToolTest.run(ToolTest.java:835) at webtool.test.Test$4.loop(Test.java:923) at webtool.test.execution.CompositeExecutionLoop.loop(CompositeExecutionLoop.java:60) at webtool.loadtest.SetupTeardownTestRunner.runtest(SetupTeardownTestRunner.java:117) at webtool.loadtest.SetupTeardownTestRunner.runSetUp(SetupTeardownTestRunner.java:64) at webtool.loadtest.sim.startup.SOAtestComponentSetupTeardownTask.doRun(SOAtestComponentSetupTeardownTask.java:76) at com.parasoft.simulator.startup.StartUpTask.run(StartUpTask.java:51) at webtool.loadtest.LoadtestPlugIn.initStartUpTasks(LoadtestPlugIn.java:565) at webtool.loadtest.LoadtestPlugIn.runScenario(LoadtestPlugIn.java:468) at webtool.loadtest.LoadtestPlugIn.runScenario(LoadtestPlugIn.java:414) at webtool.loadtest.tool.SimulatorBasedLoadTestTool.applyTool(SimulatorBasedLoadTestTool.java:88) at com.parasoft.tool.Tool.apply(Tool.java:341) at com.parasoft.gui.ToolMonitor.applyTool(ToolMonitor.java:66) at com.parasoft.tool.Tool.apply(Tool.java:341) at com.parasoft.tool.ToolUtil.isSuccess(ToolUtil.java:116) at com.parasoft.tool.SingleBatch.iterate(SingleBatch.java:38) at com.parasoft.gui.BatchExecutor.apply(BatchExecutor.java:261) at com.parasoft.gui.BatchExecutor.apply(BatchExecutor.java:90) at com.parasoft.gui.BatchExecutor.apply(BatchExecutor.java:68) at com.parasoft.gui.BatchExecutor.apply(BatchExecutor.java:59) at com.parasoft.gui.BatchExecutor.apply(BatchExecutor.java:49) at com.parasoft.gui.BatchExecutor._doActionPerformed(BatchExecutor.java:403) at com.parasoft.gui.BatchExecutor.access$0(BatchExecutor.java:352) at com.parasoft.gui.BatchExecutor$1.run(BatchExecutor.java:344)
I worked the test a little, by hardcoding the input variable as well as removing, and adjusting the script inputs, with no luck. I think this may be a bug in parasoft, if it is even supported at all. I wanted to reach out to seek additional knowledge on something I may be doing incorrectly, and possibly creation of the bug with parasoft, if this usage of the variable should be supported as load test configuration and validation of the tst passes without issue.
workspace_loc is an Eclipse variable, so in general Load Test does not know how to resolve it. However, the most common place for workspace_loc variable to be used is in file fields where a .tst file needs to reference another file. In those cases, the .tst file saves information that allows Load Test to find the referenced file even though it does not know how to resolve workspace_loc directly. So it is expected for the payload field to not resolve workspace_loc, but in file fields things should generally work. Is the use case you mention here the actual use case where you are referencing workspace_loc in your project, or is it a different case?0
We are using workspace_loc as script input, to reference a file path relative to the workspace on different machines (local mac or windows machines versus CTP location when running in automation)
reference in script:
kubeconfigPath = input + fileDelim + "TestAssets" + fileDelim + "kubernetes-config" + fileDelim + "kubeconfig_" + env + "_" + namespace + additional + ".yaml"0
A safer way to do this that will work from a script in SOAtest, Load Test, and from CTP is to use the API method ScriptingContext.getAbsolutePathFile() which will give you a reference to a file that is relative to the location of the .tst file. The ScriptingContext is one of the variables that will get passed into your script if you create a method that takes one or two arguments. You can see JavaDocs for the method by going in the SOAtest desktop to Help > Help Contents > Parasoft SOAtest Extensibility API Main and finding the reference for ScriptingContext.0
I generally do not recommend using "workspace_loc". Using "project_loc" is slighly better, since projects may or may not live under the workspace folder. However, my recommendation is to use a path relative to the tst file whenever possible. From a script, you can use com.parasoft.api.ScriptingContext.getAbsolutePathFile(String fileName).0
relative path assumes that the structure is the same both locally and on the CTP server, which may not be the case.
locally, I may have my project in workspace/service/endpoint/scenario, which would need a relative path of ../../../TestAssets/config_file and others could have their workspaces organized a little differently as well. While on the ctp server, the project is simply workspace/service which would have a relative path of ../TestAssets/config_file
For this reason, we tried to use workspace_loc as a common starting point for all referenced files such as the one above. We may have to restructure our setups and require everyone mimic the structure of CTP, but we would like to look at that as a last resort, if necessary.0
Generally .tst files and the files they reference need to be in the same relative location to each other in all environments. I don't expect things to work when referenced files are in different locations in different environments.0
ok, we will look into the use of workspace_loc, rearrange our structures to match across everyone’s system including CTP, or find a different way to access the necessary files since the built in reference location variables appear to have issues.0