To fully grasp what we will be covering you should have a basic knowledge of software testing and understand what the following terms mean:
Let us focus on a typical communication pattern where two systems communicate with HTTP request and responses:
Now that we have two systems communicating with HTTP, we can explore how we could test those systems. What happens if we wanted to test System A, but System B is temporarily unavailable? Or, what happens if System B does not exist yet at all?
In these scenarios, we can simulate System B using Traffic Parrot so that System A can still be tested. Traffic Parrot will receive the HTTP requests and send HTTP responses, pretending to be System B.
This will allow us to test System A in isolation in both typical and hypothetical situations. You will be able to simulate HTTP responses that are expected to be seen in production environments, but also non-typical error responses or failure scenarios that would usually be hard to reproduce. You can do that by configuring Traffic Parrot to respond with response messages of your choice.
Let's go through an example of how to use Traffic Parrot to simulate a system that is available via a HTTP SOAP API. Our system under test is a UV Index application that is used to fetch UV Index for a given postcode. The app connects to the UV Index HTTP SOAP API provided by the United States Environmental Protection Agency (EPA) located at https://iaspub.epa.gov/ and displays the details of the UV Index status to the user.
In our example, we will assume that the EPA UV Index SOAP API (EPA API) is available, but we would like to simulate different types of responses from that API in our testing to understand how our UV index application works in hypothetical scenarios. For example, we would like to know how it behaves for different values of the UV index or incorrect data returned by the API.
For example, if we wanted to test UV Index values like 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 and 10, we would have to find postcodes where the UV Index is exactly equal to that value when we run our tests. Searching for those postcodes would be time-consuming, and also depending on the day we might not be able to find a postcode that would give us the UV Index we want. If we wanted to test how our application behaves when the EPA API returns incorrect UV values like -5 or 'blah' there is no way to do that.
Fortunately, we can use Traffic Parrot to simulate the EPA API and return any values we need. We will create those simulators (also called mocks or virtual services) by recording HTTP SOAP traffic. We will use Traffic Parrot to record the SOAP request and response between the UV Index application and the EPA API. Then, we will modify the recorded response to simulate different value of the UV Index.
Have a look at the second half of the following video tutorial to see how to generate dynamic SOAP messages.
Then, you can familiarize yourself with the Dynamic Responses Tutorial which contains more details on different options of generating dynamic responses.