The new model creates a real revolution in the development of automation and opens up endless other possibilities.
The first article presented an application of Mirror Model for UI tests, but the main concepts of the new model also applies to other types of tests.
Let’s talk about API testing
API tests are designed to send a certain request and verify a correct reponses or verify a certain change that happened in the system or any other testing task.
Request can be done with a large aggregate of parameters and the requests themselves can also be different sequences of requests.
Why should we use the concept of mirror model?
Allow us to run an exploratory testingWill make tests clean
Any transition to the concept of mirror model means that the focus of the tests is on DATA
So how the automation infrastructure look like?
- Each service will have its own controller.
- A controller will contain functions according to the various APIs that are in it and will publish an event with the request and response data.
- The appropriate validations registered for this type of event will perform a check of the API answer, each in its own field and taking into account the last updated system status.
- Only the validation layer updates and reads the system status layer.
What about the test?
All the requirements are built in the automation infra, so the tests can only deal with multiple variations of data or randomization of API calls (exploratory testing).
Need more example? have questions?
gilz1407@gmail.com
