Forum Discussion

jrziggy's avatar
jrziggy
Occasional Contributor
3 months ago

Changing environment in Jenkins mid-test

I have a ReadyAPI suite with three test cases.

  1. First is a test case to pull all the needed data using data sources.
  2. Then a test case that runs some SOAP requests.
  3. The next test case has a first step to change the environment using a groovy script. The following test steps are the same as the second test case, so we can compare the responses between two environments with same data from the first test case.

The problem I'm seeing is that in the ReadyAPI application it works great. In Jenkins (using testrunner), the environment endpoints don't change like they do in the ReadyAPI app after the groovy script environment change.

Here's the groovy script that works fine in the ReadyAPI application. And, in the Jenkins console log it outputs what I expect, but the test steps that follow continue to use the original environment set in the testrunner command line with the -E LOCAL.

//To get the active Environment from, example "LOCAL"
def env = testRunner.testCase.testSuite.project.getActiveEnvironment().getName() 
log.info("Active Environment was: " + env)
//To change the active Environment to, example "CLOUD"
env =  testRunner.testCase.testSuite.project.getEnvironmentByName("CLOUD");
testRunner.testCase.testSuite.project.setActiveEnvironment(env)
log.info("Active Environment now: " + testRunner.testCase.testSuite.project.getActiveEnvironment().getName())

Do I have to go outside the test files (groovy script saved in the project) to set the environment like I do initially to set the environment "-E LOCAL" command for testrunner? If so, what's the syntax on that?

1 Reply

Sort By
  • mnwill117's avatar
    mnwill117
    Occasional Contributor
    5 days ago

    reply from smart bear: 


    This is a known limitation of ReadyAPI’s TestRunner (CLI). When you use the -E <envName> flag, the environment is locked in at runtime startup, and internal changes made during execution via scripts do not impact actual request resolution for endpoint/credentials/etc.
    In short:
    Changing the environment dynamically via Groovy script during a TestRunner execution has no effect on actual requests.
    This works in the GUI because the execution context is fully dynamic — but the CLI loads the environment once at startup, making it immutable during test execution.


    One option you can try to do to get around this is to run TestRunner Twice (One per Environment)
    Which would probably be the most reliable and maintainable solution:
    Run the suite twice, once for each environment:
    testrunner.bat -E LOCAL -s "SuiteName" -c "TestCase1" -RJUnit -r <project-file>
    testrunner.bat -E CLOUD -s "SuiteName" -c "TestCase2" -RJUnit -r <project-file>
    You can pass in shared data through properties, or persist data to disk (via Excel, CSV, JSON) between executions.