Forum Discussion

mrugglesaz's avatar
mrugglesaz
Occasional Contributor
11 years ago

SoapUI Environments Functionality Only "Half-Baked"

Smart Bears:

I recently started using the Environments functionality in soapUI Pro 4.5.1 and although this feature greatly improves the efficiency/reusability of certain test cases in my project, there is a list of things that I've found that makes me think that this feature needs to cook a little longer to make it flawless. Below is a list of improvements in order of importance.

Issues with soapUI Environment Functionality:

    1. Adding new WSDL's to a project does not update existing environments.

    • Adding/deleting a WSDL does not refresh tree view. You have to close & reopen soapUI to see the changes.
    • Effectively, you have to delete all the environments so that cloning test cases starts working again correctly.

    2. Changing environments does not change the associated JDBC connection string in various JDBC test steps.

    3. Selecting an available Environment in the drop-down on the Overrides tab in the TestRunner dialog does nothing.

    4. Related to the above, you have to click the Save All Projects button after selecting an environment from any other drop-down to apply the change to the TestRunner. Without clicking the Save All button, the TestRunner remembers the last environment that was used and does not apply the endpoints for the newly-selected environment.

    5. After adding a blank environment, if you open a blank JDBC connection associated to the environment, but decide to cancel out of the dialog before entering any information, the JDBC connection is deleted from the environment. [BUG]

    6. Related to the above, there should be some interface in the individual environments for adding/removing JDBC connections that are available at the project level. There should be some mechanism to mark a JDBC connection as the default for any given environment. This would create a hierarchy where the project contains all the available environments and the separate environments are able to be configured from the overall list stored at the project level. This is a must for any projects that contain a combination of tests that are used in both TEST/PROD.

    7. No ability to sort the order or move the environments in the list.

    8. When adding new environments at the project level, the F2 and ENTER keys should provide the ability to edit cells and open environments, respectively. Adding new environments should be an activity that can be performed without a mouse.

    9. Overall, the ability to add, edit, and delete environments needs to be improved.


Since I am constantly editing my soap project and adding new WSDL's to it (it is a template project that's used to run validation tests during production implementations), the shortcoming listed in Item #1 has caused me to start storing my endpoints in Groovy scripts, which are used to update my test steps based on the Environment value selected. After adding and deleting a list of 30 environments with 16 endpoints each a couple of times, I quickly grew tired of that activity and moved my endpoint dynamics to Groovy, which, believe me, I understand defeats the purpose of adding Environments to a project in the first place. Environments are great if you never plan to update your project again. However, in the real world, projects are reused and updated all the time. There are many things in soapUI that are configurable and dynamic; adding new WSDL's to Environments should be one of them.

Thanks,

Mark A. Ruggles

3 Replies

  • jafari's avatar
    jafari
    Occasional Contributor
    Hi Mark,

    Thank you very much for the thorough and concrete feedback. I am just letting you know that your critique has been noted, and that we will make sure to let you know when we have any updates to these concerns of yours.

    Best regards,
    Arian
    SmartBear Sweden
  • Hi,

    Any update on this? I have been facing the JDBC issues [the JDBC connection doesnt change to the new environment after switching it from the previous environment].
    I am using the latest SOAP UI version [4.6.0].

    Please let me know if there is any workaround for the same.

    Regards,
    Sagar
  • mrugglesaz's avatar
    mrugglesaz
    Occasional Contributor
    SagarArcher wrote:
    Hi,

    Any update on this? I have been facing the JDBC issues [the JDBC connection doesnt change to the new environment after switching it from the previous environment].
    I am using the latest SOAP UI version [4.6.0].

    Please let me know if there is any workaround for the same.

    Regards,
    Sagar


    Sagar:

    I figured out a workaround of my own. Here's the procedure that I use. One caveat, you must use the Environments functionality to make this work.

    1. I created all of my JDBC connection strings per environment as Global Properties. The Password must be included in the string.
    2. I have a Groovy script that uses case statements that assign the appropriate JDBC connection string to a Project Proeprty for the Environment selected in the drop-down.
    3. I added a data pull in the Connection String field in the JDBC step that gets the string from the Project Property. The Password field is left blank in the JDBC step.
    4. I added a line in the TearDown Script to set the Project Property to blank again after the test is executed to remove the Password from it.

    The design above keeps sensitive database passwords out of the project and keeps them in Global Properties, which are specific to a user's local copy of SoapUI. This is the best design I could think of to get around the disconnect between Environments and JDBC steps. The above design does work and I have updated all of my tests to use it. Now when I select a new Environment value from the drop-down, my Groovy script takes cares of assigning the appropriate JDBC connection string for that environment. Give it a try and let me know if you have any questions.

    Mark A. Ruggles