Fake it until you make it - Stubby4j

While I was searching for a Contract Testing tool, I came across this interesting Stubby4j. Stubby4j is highly flexible and configurable tool for service virtualization or mock API server. It is actually a HTTP server that uses embedded Jetty which allows stubbing of external systems with ease for integration, contract & behavior testing.

In today's microservices era, it is very common that an API you depend on doesn't exist or isn't complete.  To stay productive in those situations, we can use these mock API servers which constantly produces the desired response. We can also use them while testing edge cases as the real APIs don't reliably produce these scenarios.

Key Features of Stubby4j:

• Emulate external webservice in a SANDBOX for your application to consume over HTTP(S)
• HTTP request verification and HTTP response stubbing
• Regex support for dynamic matching on URI, query params, headers, POST payload (ie:. mod_rewrite in Apache)
• Dynamic token replacement in stubbed response, by leveraging regex capturing groups as token values during HTTP request verification
• Record & Replay. The HTTP response is recorded on the first call, having the subsequent calls play back the recorded HTTP response, without actually connecting to the external server
• Dynamic flows. Multiple stubbed responses on the same stubbed URI to test multiple application flows
• Fault injection, where after X good responses on the same URI you get a bad one
• Serve binary files as stubbed response content (images, PDFs. etc.)
• Embed stubby4j to create a web service SANDBOX for your integration test suite

Quick Start:

1. Download the latest stubby4j version (the JAR archive).

2. Create the following local YAML file:

 -  request:
      method: GET
      url: /hello-world
 
   response:
      status: 200
      headers:
         content-type: application/json
      body: Hello World!

3. Execute the downloaded stubby JAR using command

java -jar stubby4j-x.x.xx.jar -d <PATH_TO_YOUR_CREATED_LOCAL_YAML_FILE>

4. Navigate to http://localhost:8882/hello-world to get the stubbed response “Hello World!”

5. Navigate to stubby4j admin portal at http://localhost:8889/status to see what has been stubbed & other useful data

Apart from using it is as a jar file, we can also use Stubby4j as a docker container.

Running Stubby4j as Docker Container:

Dockerfile example:

FROM <any-image-that-includes-java>
RUN wget http://central.maven.org/maven2/io/github/azagniotov/stubby4j/6.0.1/stubby4j-6.0.1.jar -O /usr/local/stubby4j.jar
EXPOSE 8889 8882
CMD java -jar /usr/local/stubby4j.jar -d no.yaml --location "0.0.0.0" --watch 

By default http://localhost:8882 is the stubs portal, http://localhost:8889 is the admin portal. They should be exposed externally.

The command for running a docker image

docker run -p 127.0.0.1:8889:8889 127.0.0.1:8882:8882 <your-image>

How QE can use Stubby4j:

• Specifiable mock responses to simulate page conditions without real data.
• Ability to test polling mechanisms by stubbing a sequence of responses for the same URI
• Easily swappable data config files to run different data sets and responses.
• All-in-one stub server to handle mock data with less need to upkeep code for test generation

There are several tools available for Service Virtualization or mock API server. But Stubby4j has the following advantages over other tools.

1. You can simulate responses from real servers
2. Simulates support for different types of HTTP authentication.
3. Enables delayed responses for performance and stability testing
4. Allows invocation of service call for services which are not ready yet or in-accessible due to various reasons.

Apart from it's advantages, stubby4j also has below limitations.

1. You can neither change the name of the mapping file nor break it in multiple files.
2. Data that you capture from request using regular expression can be used either in response mapping or response body (if response body is specified in separate file)
3. There is no way to generate dynamic dates, random numbers etc. The data which is captured from the request can only be used in response.
4. If your simulator application grows, .yaml is not maintainable

There is a tool called Stubmatic which adresses many of these limitations. 

For more information on stubby4j, please visit https://github.com/azagniotov/stubby4j

You can also look at below alternatives for Stubby4j:

• Wiremock
• Betamax
• REST-driver 
• MockServer 
• Moco 
• Mountebank