My aim for this post is to guide you through the necessary steps required to create an Automated Compliance Test suite in SoapUI. This is meant as an overview of the process and not an in-depth guide. If you require more details regarding any of the steps in this post please refer to the SoapUI Website. Please also note that this guide is created with the SoapUI Open Source application in mind and there may be slight differences if you want to create this type of test using the paid version (SoapUI NG Pro).
Below you have an overview of how to create an automated compliance test suite either using a REST or SOAP web service or a mocked web service (mocked web services can be created and invoked using this guide).
- Create a new Project. This will contain your Rest Request Methods (a collection of configured calls to your web services) and your test suite (where all your tests will be kept). When creating the project, you have to make a choice about the type of project that you are going to create. You have the option of either creating a SOAP or a REST project (what you choose will depend on the type of API you want to test).
- Create the initial REST request methods (GET, POST, PUT, PATCH, DELETE, etc.). There should be one REST request method for each HTTP request included in the web service you are trying to test. If you are planning to test a SOAP web service and you have been provided with a WSDL file you can create a request method using the following guide. If you need to test a RESTful API then the setup of your REST request method using this guide.
- Once you have set up the REST request methods you can thencreate a Test Suite for the Project. Right click on the project and choose “New Testsuite” to create the test suite. A project can have as many test suites as you require, though it is normal practice to have either only one test suite (testing all the web services in a project) or one test suite per web service (for larger APIs).
- Tests can then be created within the suite to test a particular web service or functionality. The basic instructions for setting up a test case can be found here.
- Within each test you have to add test steps. A test step represents a single functionality of the web service (such as a SOAP, REST or any other type of request), or another specialised type of test step action (such as a Groovy Script, Delay, Mock Response, Properties Transfer etc). You can set properties that can be used within your test steps (or in your assertions or scripts) at different levels of the project (Project, Test Suite, Test Case etc.).
- In each of the test steps where you have created a web service request test you will probably want to add some kind of assertion (if you do not add an assertion to the test step it will not be marked as passed when you run your automated tests). You have a number of assertion options available to you when using SoapUI:
- Property content (contains/does not contain): can be used to assert that an expected string is present in the response.
- Valid/Invalid HTTP codes.
- Schema Compliance: Validates that the schema of the response is valid with the associated WSDL or ASDL schema definition (a schema will have to be previously defined in the projects .wadl file).
- Once you have created all of your tests you can run them in the test suite by using the test runner. This can either be invoked from command line (which is useful when integrating with a CI platform) or via the SoapUI GUI. A guide of how to run the test runner from the command line can be found here. If you prefer to watch the live status of the tests whilst they are being executed (a graphical representation rather than CLI output) this can be achieved by double clicking on the test suite and choosing the option to run the test suite.
Written by David Creer