mrugglesaz
12 years agoOccasional Contributor
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:
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
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