Service Virtualization with WireMock

Published in

Finartz

5 min readDec 9, 2020

Choosing the right service virtualization tool to be used for service mocking is of great importance in the rapid success of our project. Of course, we know that we need to use a simple and fast tool in this context.

We evaluated commonly used tools WireMock, Mockhito and Traffic Parrot, etc. that in the service test automation project at Finartz . Among these tools, we saw that WireMock is a simpler and faster-to-apply tool than others. This tool, which provides a lot of flexibility, has a comfortable and applicable structure, especially for testers.

In this article, I will refer to the basic concepts of the WireMock tool, which is effectively used in test automation projects of service-based applications.

What is Service Virtualization?

Service virtualization is a practice used to simulate the behavior of external or integrated services on which the system is dependent. It ensures that the system to be tested is isolated by minimizing dependencies. The virtualization of these services, which are beyond our control, will greatly speed up the testing and development processes. In addition to this, possible data-based problems are prevented. Thus, both system dependencies and effects on associated systems are minimized.

WireMock Versions

There are two versions of WireMock as Standard and Standalone. In the Standard version, request -response definitions can only be made as stateful behaviors, while in the Standalone version, additional record / playback and request - response mapping can be done.

WireMock Standart

First, we add the standard WireMock dependency to our Maven project.

<dependency>
   <groupId>com.github.tomakehurst</groupId>
   <artifactId>wiremock-jre8</artifactId>
   <version>2.27.2</version>
   <scope>test</scope>
</dependency>

We are now ready to use WireMock. We can create our Mock class and define “Stub”. Before defining the stub, we define the WireMock rule to set the mock server. Rule definition can be made in two ways.

Mock server lifecycle management can be done with or without the WireMock JUnit Rule. It starts the mock server before each scenario and stops it after the scenario.

Without JUnite

Notification

A notifier is used to view WireMock logs on the console.

What is the Stub?

The objects we use for mock definitions are called Stub. Mock and Stub are basically the same thing, but with some minor differences. The definition of behavior with a predetermined response as Stateful is called Stub. Mock are objects where the response is dynamically generated according to expected behavior.

As it can be understood from the Stub definition here, post requests coming to “/ user / add” path are answered with 200 status code and “success.json” with “Content-Type”: “application / json” header. It takes “success.json” from the “__files” folder in the project, which it will return as a response.

It will be better understood with a sample project. This project was created using Cucumber and TestNG. To run the tests with maven, just follow the command below.

mvn clean test verify 
-Dsurefire.suiteXmlFiles=src/test/resources/testng.xml

Or you can also run with cucumber if you wish

WireMock Standalone

It is the server version that can work independently. We are downloading the WireMock standalone jar file that we can easily run. To run it, all we have to do is open the command line in the directory we downloaded and apply the following command.

$ java -jar wiremock-standalone-2.27.2.jar --verbose --port 8089

In this way, the WireMock server will run at http://localhost: 8089. The Verbose console is an option we use to display logs. There are many options you can use according to your needs. You can get more information about options on WireMock’s official website.

When WireMock runs, it will create two folders named mappings and __files in the directory where it is located. Stub definition can be made with 2 methods in standalone version.

HTTP Post Request

$ curl -X POST \
--data '{ "request": { "url": "/user/add", "method": "POST" }, "response": { "status": 200, "body": {\"id\":\"99\",\"userName\":\"admin\",\"roleName\":\"admin\" }}' \
http://localhost:8089/__admin/mappings/new

2. By creating a json file under the mappings folder

In the scenario specific, we create request / response definitions of the Jsons we need to return and save them on the mock server. There may be situations when we need to return different responses to the same requests at our scenarios. In this case, we can provide a response based on request matches. The last recorded response will be returned for definitions with the same request match.

Request Matching

Request matching is used to match the fields available in the incoming request header or body.

Body Transformer Plugin

If we want to change the parameters in the received request, we can use the “Body Transformer” extension. First of all we add dependency to our pom file.

<dependency>
   <groupId>com.opentable</groupId>
   <artifactId>wiremock-body-transformer</artifactId>
   <version>1.1.6</version>
</dependency>

In this example, we return the userName and roleName information in the reply. The use of standard version is as follows

The use of WireMock in Standalone version is as follows

Verification

This makes it possible to verify that a request matching a specific pattern was received, and also to fetch the requests’ details.

In this code snippet it is confirmed that the request came to the “/ user / add” path with the header as “application / json” 3 times.

This can be done by posting a JSON document containing the criteria to http://<host>:<port>/__admin/requests/count:

For WireMock Stanalone

Simulating Faults

One of the main reasons it’s beneficial to use web service fakes when testing is to inject faulty behavior that might be difficult to get the real service to produce on demand. In addition to being able to send back any HTTP response code indicating an error, WireMock is able to generate a few other types of problem.

Per-stub fixed delays

A stub response can have a fixed delay attached to it, such that the response will not be returned until after the specified number of milliseconds:

Bad responses

It is also possible to create several kinds of corrupted responses:

The Fault enum has the following options:

EMPTY_RESPONSE: Return a completely empty response.

MALFORMED_RESPONSE_CHUNK: Send an OK status header, then garbage, then close the connection.

RANDOM_DATA_THEN_CLOSE: Send garbage then close the connection.

CONNECTION_RESET_BY_PEER: Close the connection, setting SO_LINGER to 0 and thus preventing the TIME_WAIT state being entered. Typically causes a “Connection reset by peer” type error to be thrown by the client. Note: this only seems to work properly on *nix OSs. On Windows it will most likely cause the connection to hang rather than reset.

In JSON (fault values are the same as the ones listed above):

I tried to explain how to use WireMock simply.

Thanks for reading. You can find the example WireMock test project code on https://github.com/uguraltas/WireMock-Test-example

See you in the next article. Best Regards.