Are variable and secrets supposed to be available to tests as we have built tests that require these but are all failing?
Hello seanhickey,
Variables and secrets should be available to tests when they are included in the environment selected for the test run. Please confirm that the test is running with the same PowerShell Universal environment used by the scripts that work as expected.
For custom environments, please check the environment’s variable configuration. Default environments import all variables, but custom environments must explicitly include the appropriate variables. Secrets can also be accessed with the `$Secret:` scope.
As a minimal test, please try validating only that a non-sensitive variable and secret are available, without writing their values to output. For example, verify whether the variable is non-null and whether `$Secret:<secret-name>` resolves.
Please share the following, sanitized:
- PSU version and build
- Selected test environment
- Whether that environment is default or custom
- Whether the secret has roles assigned
- Exact sanitized test failure or error output
References:
https://docs.devolutions.net/powershell-universal/automation/tests
https://docs.devolutions.net/powershell-universal/platform/variables
Best regards,
Ruben Tapia
Thank you. We are using the same environment across scripts, apps, apis and tests which is the "PowerShell 7" one, not a custom one.
We built some debugging in the test to write out a log in the file system and verified that all variables and secrets are showing with no value, they are all null
- PSU version and build: Tested on 2026.2.0, 2026.2.1 & 2026.2.2
- Selected test environment: PowerShell 7
- Whether that environment is default or custom: Default
- Whether the secret has roles assigned: No roles used on them
- Exact sanitized test failure or error output: All tests which require variables or secrets simply show failed in the console. Testing a SQL connection simply returns that it's parameters are null.
SQL: ERROR ParameterBindingValidationException: Cannot validate argument on parameter 'Database'. The argument is null or empty. Provide an argument that is not null or empty, and then try the command again.
Thank you. We are using the same environment across scripts, apps, apis and tests which is the "PowerShell 7" one, not a custom one.
We built some debugging in the test to write out a log in the file system and verified that all variables and secrets are showing with no value, they are all null
- PSU version and build: Tested on 2026.2.0, 2026.2.1 & 2026.2.2
- Selected test environment: PowerShell 7
- Whether that environment is default or custom: Default
- Whether the secret has roles assigned: No roles used on them
- Exact sanitized test failure or error output: All tests which require variables or secrets simply show failed in the console. Testing a SQL connection simply returns that it's parameters are null.
SQL: ERROR ParameterBindingValidationException: Cannot validate argument on parameter 'Database'. The argument is null or empty. Provide an argument that is not null or empty, and then try the command again.
@seanhickey
Hello seanhickey,
Thank you for confirming that the behavior occurs with the default PowerShell 7 environment and across PSU 2026.2.0, 2026.2.1, and 2026.2.2. The additional details about the variables and secrets resolving to null are helpful.
We will perform lab testing today to validate this behavior in a controlled environment. Once we have completed the reproduction and collected the necessary technical evidence, we will escalate the case to our Development team for further review.
We will update this topic with our findings and any additional information required.
Best regards,
Ruben Tapia
Hello seanhickey,
Thank you for your patience. Our Development team has confirmed this behavior as a bug: variables and secrets are currently not being loaded during test execution.
The team has recorded the issue and will work on a correction. We do not yet have a confirmed target version or release date, but we will update this topic when verified information becomes available.
Best regards,
Ruben Tapia