Mockingjay lets you define the contract between a consumer and producer and with just a configuration file you get:
- A fast to launch fake server for your integration tests
- Configurable to simulate the eratic nature of calling other services
- Consumer driven contracts (CDCs) to run against your real downstream services.
Mockingjay makes it really easy to check your HTTP integration points. It's fast, requires no coding and is better than other solutions because it will ensure your mock servers and real integration points are consistent so that you never have a green build but failing software.
- Installation - Download a binary, use a Docker image or
go get
- Rationale
- See how mockingjay can easily fit into your workflow to make integration testing really easy and robust
---
- 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...
$ mockingjay-server -config=example.yaml -port=1234 &
2015/04/13 14:27:54 Serving 3 endpoints defined from example.yaml on port 1234
$ curl http://localhost:1234/hello
{"message": "hello, world"}
$ mockingjay-server -config=example.yaml -realURL=http://some-real-api.com
2015/04/13 21:06:06 Test endpoint (GET /hello) is incompatible with http://some-real-api - Couldn't reach real server
2015/04/13 21:06:06 Test endpoint 2 (DELETE /world) is incompatible with http://some-real-api - Couldn't reach real server
2015/04/13 21:06:06 Failing endpoint (POST /card) is incompatible with http://some-real-api - Couldn't reach real server
2015/04/13 21:06:06 At least one endpoint was incompatible with the real URL supplied
This ensures your integration test is working against a reliable fake.
http://{mockingjayhost}:{port}/requests
Calling this will return you a JSON list of requests
Mockingjay has an annoying friend, a monkey. Given a monkey configuration you can make your fake service misbehave. This can be useful for performance tests where you want to simulate a more realistic scenario (i.e all integration points are painful).
---
# Writes a different body 50% of the time
- body: "This is wrong :( "
frequency: 0.5
# Delays initial writing of response by a second 20% of the time
- delay: 1000
frequency: 0.2
# Returns a 404 30% of the time
- status: 404
frequency: 0.3
# Write 10,000,000 garbage bytes 9% of the time
- garbage: 10000000
frequency: 0.09
$ mockingjay-server -config=examples/example.yaml -monkeyConfig=examples/monkey-business.yaml
2015/04/17 14:19:53 Serving 3 endpoints defined from examples/example.yaml on port 9090
2015/04/17 14:19:53 Monkey config loaded
2015/04/17 14:19:53 50% of the time | Body: This is wrong :(
2015/04/17 14:19:53 20% of the time | Delay: 1s
2015/04/17 14:19:53 30% of the time | Status: 404
2015/04/17 14:19:53 9% of the time | Garbage bytes: 10000000
- Go 1.3+ installed ($GOPATH set, et al)
- Node 4.2.x (for the frontend)
- golint https://github.com/golang/lint
$ go get github.com/jteeuwen/go-bindata/...
$ go get github.com/elazarl/go-bindata-assetfs/...
$ go get github.com/quii/mockingjay-server
$ cd $GOPATH/src/github.com/quii/mockingjay-server
$ ./build.sh
$ cd ui/
$ npm install
$ npm run dev
This will rebuild the frontend assets on file changes. Then in another terminal:
$ ENV=LOCAL mockingjay-server -config=$PATH-TO-CONFIG
The env local ensures the web server serves your constantly building assets, rather than the bundled ones made on build.sh
.
MIT license