Rationale

In the hip exciting world of SOA/microservices with heavy investment in PaaS/IaaS you want to be able to quickly iterate over small services and deploy to live quickly and without fear of breaking things.

If you are using this kind of architecture you will be faced with the challenge of ensuring that your huge numbers of services can actually talk to each other.

You will probably employ things like versioning to help but you might also be spending time writing consumer driven contracts (CDCs) to ensure your integration points are working.

In addition you might be writing integration tests against fakes/stubs to check your code can send the correct requests and be able to parse responses.

If you squint hard enough, you can imagine that the requirements for both CDCs and fake servers are the same.

Given a particular request
When I send it to the real OR fake server
Then I expect a particular kind of response. 

Yet with this set up you are duplicating this information with code in two different places which can lead to:

• Inconsistencies
• Code/logic creeping into your fake servers
• Green builds even though the fake is "wrong"

What mockingjay enables you to do is to capture these requirements in one configuration file.

---
 - name: My very important integration point
   request:
     uri: /hello
     method: POST
     body: "Chris" # * matches any body
   response:
     code: 200
     body: '{"message": "hello, Chris"}'   # * matches any body
     headers:
       content-type: application/json

# define as many as you need...

From this you can create a fake server to write integration tests with and also check the service you are dependant on is consistent with what you expect.

Main advantages

• No coding whatsoever, so no naughtiness in fake servers overcomplicating things. Even non developers can add new scenarios to test with.
• The contract is defined once, rather than dispersed across different scripts which you have to keep in sync.
• Entirely language agnostic. If you speak HTTP you can use mockingjay.
• Checks the structure of the data (JSON and XML only) rather than the contents, which will reduce flakiness of your builds.
• Both the fake server and CDCs are really fast to run, to help keep your builds fast.

Drawbacks/constraints

• You can only express your consumer-producer interaction in terms of isolated request/responses. Sometimes you might need to test a number of requests which are dependant on each other.