Submit and vote on feature ideas.

Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.

Not able to send Environment Variables in External Tool arguments

goofy78270
goofy78270 Posts: 133

I am setting up an external tool to execute some batch files, but rather than hardcoding a path, everyone has an environment variable setup to the desired location. However, when I use the %variableName% structure which the external tool understands, Parasoft disables the tool for some reason.

Is there a setting to allow these variables to be passed? I tried escaping them with various characters, but no luck.

Simple example using %USERPROFILE% which should equate to C:\Users\myname.

Hardcoded path test and results:

Variable Path setup and disabled step in Test Case Explorer Pane:

Disabled Step (light gray versus black)

Comments

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭

    Use syntax ${env_var:name_of_env_var}

  • goofy78270
    goofy78270 Posts: 133

    Thanks, I will try that.

    Also, how would I capture the info from the input tab (like ${workspace_loc}), in a variable? In script I simply say input and it works, but here, it requires something different which I am unsure about since I could not find any documentation on it.

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭

    You can't directly resolve all types of arbitrary variables in a script. However, there are other approaches available.

    Instead of trying to resolve "${env_var:USERPROFILE} you can use java.lang.System.getenv("USERPROFILE") method insead.

    Instead of trying to resolve "${wokspace_loc}", I recommend locating files relative to the tst file instead of the workspace location. Use com.parasoft.api.ScriptingContext.getAbsolutePathFile(String filename)

    To resolve test suite variables use com.parasoft.api.ScriptingContext.getValue(String variableName)

    To resolve data source columns use com.parasoft.api.ScriptingContext.getValue(String dataSourceName, String columnName)

    To resolve data bank columns, same as previous but use "Generated Data Source" for the "dataSourceName" argument.

    To resolve tst environment variables (not OS/shell variables), use com.parasoft.api.ScriptingContext.getEnvironmentVariableValue(String name)

  • goofy78270
    goofy78270 Posts: 133
    edited April 2020

    Those are great from within an extension tool, but I am unable to use scripts with an external tool and the arguments or executable path, so how would you recommend I use variables in these areas, if allowed?

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭
    edited April 2020

    so how would you recommend I use variables in these areas, if allowed?

    What type of variable are you having trouble using in which tool configuration field? I thought you confirmed that using ${varName} syntax was working for you, like ${env_var:USERPROFILE}. I thought your last question was asking how to use it in a script.

  • goofy78270
    goofy78270 Posts: 133

    Sorry, I am using ${workspace_loc} in the input section of my external tool, and trying to reference that value as a argument for the location of a file ${workspace_loc}/TestAssets/Files/a.txt.

    However, using ${workspace_loc} or ${input} in the arguments path does not work. The stdout is:

    error: CreateFile ${wokspace_loc}\TestAssets\Files\a.txt: The system cannot find the path specified.
    

    I also tried including simple variables from the test suite as the file name, and that did not work either. The test simply runs forever (stopped the test after running over a minute).

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭
    edited April 2020

    using ${workspace_loc} or ${input} in the arguments path does not work.

    "${input} is not a built-in variable. The text on the Input tab of the External tool is simply passed to the STDIN stream of the process (like keyboard input). Also, I think text on the Input tab is passed to STDIN as-is unless you pick the File option with "Resolve environment variables" box enabled. If there is a value you need to send as an argument and to STDIN (to simulate keyboard input) then you would put the value in both places. If you are only trying to pass arguments then know the Input tab is not what you use for this.

    Concerning the arguments table, variables like ${workspace_loc}, can be used and will be resolved. I verified this is working. So, for the "\C" flag, setting the argument value to ${wokspace_loc}\TestAssets\Files\a.txt will work.

    A couple other things to consider:
    Consider whether you can use a relative path. The executable is run with the current working directory (CWD) being the folder containing the tst file. This simplifies use of relative paths. For example, if your tst is in TestAssets just try passing a relative path like "Files\a.txt".

    Instead of using "${wokspace_loc}\TestAssets" it would be better to use "${project_loc:TestAssets}". This way you use the correct path, regardless of where the directory for your "TestAssets" project happens to live on disk. Project directories don't have to live under the workspace directory.

  • goofy78270
    goofy78270 Posts: 133

    Unsure if there is a conflict in versions here, but variables, either ${wokspace_loc} or ${project_loc:TestAssets}, never appear to get resolved as they just keep the clock going for the test (I stop it after a minute of running and no output.

    I have included my simple test that never seems to complete (i only run 1 step at a time)

    Side note: Is there a way to see what is actually sent to stdin?

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭
    edited April 2020

    Variables are resolving. Your command line is wrong. Your External Tool is opening cmd.exe which just sits there waiting for input.

    You need to change "\C" to "/C". (command line switches for cmd.exe use forward slashes)

    After changing "\C" to "/C" I ran your example and can see "Hello World" from your .bat file being captured in the Edit tool you have changed to the Console output.

    In your example, I can also just use the relative path "test.bat" (without variables) if I put your bat file in the same folder as your tst file. So, it is up to you whether or not you want to use a variable to build an absolute path but I'm just letting you know it often isn't necessary, where relative paths work just fine too.

  • goofy78270
    goofy78270 Posts: 133

    Concerning the arguments table, variables like ${workspace_loc}, can be used and will be resolved. I verified this is working. So, for the "\C" flag, setting the argument value to ${wokspace_loc}\TestAssets\Files\a.txt will work. >

    Sorry, this "\C" was set based on your comment above I replaced it and have mixed results.


    Since I have an option that works, I am good for now.

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭

    Happy to help. Variables do resolve :)

    Your first test failed because you have another typo. The variable is "${workspace_loc}" (your are missing an 'r'). Sorry for typos in my own quick typing here. Anyway, I recommend you using "${project_loc:TestAssets}" over ${workspace_loc} anyway.