Mocks for microservice environments
You’ve just found a new way of mocking microservices!
An example config that demonstrates the common features of Mockintosh:
services:
- name: Mock for Service1
hostname: localhost
port: 8000
managementRoot: __admin # open http://localhost:8001/__admin it in browser to see the UI
endpoints:
- path: "/" # simplest mock
- path: "/api/users/{{param}}" # parameterized URLs
response: "simple string response with {{param}} included"
- path: /comprehensive-matching-and-response
method: POST
queryString:
qName1: qValue # will only match if query string parameter exists
qName2: "{{regEx '\\d+'}}" # will require numeric value
headers:
x-required-header: someval # will cause only requests with specific header to work
body:
text: "{{regEx '.+'}}" # will require non-empty POST body
response: # the mocked response specification goes below
status: 202
body: "It worked"
headers:
x-response-header: "{{random.uuid4}}" # a selection of random/dynamic functions is available
x-query-string-value: "{{request.queryString.qName2}}" # request parts can be referenced in response
Mockintosh is a service virtualization tool that’s capable to generate mocks for RESTful APIs and communicate with message queues to either mimic asynchronous tasks or to simulate microservice architectures in a blink of an eye.
The state-of-the-art mocking capabilities of Mockintosh enables software development teams to work independently while building and maintaining a complicated microservice architecture.
Key features:
In this article we explain how and why Mockintosh was born as a new way of mocking microservices.
Download the latest installer EXE from releases section and launch it. Follow the steps in wizard to install Mockintosh.
To launch Mockintosh in “quick demo” mode, just start it via Start Menu.
To start Mockintosh with customized configuration and command-line switches, open Command Prompt and start
with mockintosh --help
command there. See also a section below.
Install Mockintosh app on Mac using Homebrew package manager:
$ brew install up9inc/repo/mockintosh
Install Mockintosh Python package using pip
(or pip3
on some machines):
$ pip install -U mockintosh
Run following command to generate example.yaml
file in the current directory:
$ mockintosh --sample-config example.yaml
then, run that config with Mockintosh:
$ mockintosh example.yaml
And open http://localhost:9999 in your web browser.
You can also issue some CURL requests against it:
curl -v http://localhost:8888/
curl -v http://localhost:8888/api/myURLParamValue123/action
curl -v "http://localhost:8888/someMoreFields?qName1=qValue&qName2=12345" -X POST -H"X-Required-Header: someval" --data "payload"
Once the installation complete, you can start Mockintosh with Jinja2 used as templating language. Use a JSON/YAML configuration as an argument, e.g. example.yaml:
$ mockintosh example.yaml
and you should be seeing a web page like this whenever you visit localhost:8001:
Alternatively, you can run Mockintosh as Docker container:
$ docker run -it -p 8000-8005:8000-8005 -v `pwd`:/tmp up9inc/mockintosh /tmp/config.json
Please note the -p
flag used to publish container’s ports and -v
to mount directory with config into container.
After server starts, you can issue requests against it. For example, curl -v http://localhost:8000/
would
respond hello world
. Also, consider opening Management UI in your
browser: http://localhost:8000/__admin. Management UI offers visual tools to see available mock endpoints, traffic log
and many other features.
The list of command-line arguments can be seen by running mockintosh --help
.
If you don’t want to listen all of the services in a configuration file then you can specify a list of service
names (name
is a string attribute you can set per service):
$ mockintosh example.yaml 'Mock for Service1' 'Mock for Service2'
Using --quiet
and --verbose
options the logging level can be changed.
Using --bind
option the bind address for the mock server can be specified, e.g. mockintosh --bind 0.0.0.0
Using --enable-tags
option the tags in the configuration file can be
enabled in startup time, e.g. mockintosh --enable-tags first,second
Using --sample-config
will cause Mockintosh to write the example configuration file into specified location.
Note: sending SIGHUP to Mockintosh’s process will cause it to re-read configuration file and restart the server.
Note: This feature is experimental. One-to-one transpilation of OAS documents is not guaranteed.
It could be a good kickstart if you have already an OpenAPI Specification for your API. Mockintosh is able to transpile an OpenAPI Specification to its own config format in two different ways:
--convert
Using the --convert
one can convert an OpenAPI Specification to Mockintosh config.
JSON output example:
$ wget https://petstore.swagger.io/v2/swagger.json
$ mockintosh swagger.json -c new_config.json json
YAML example:
$ mockintosh swagger.json -c new_config.yaml yaml
If you start Mockintosh with a valid OpenAPI Specification file then it automatically detects that the input is an OpenAPI Specification file:
$ mockintosh swagger.json
and automatically starts itself from that file. Without producing any new files. So you can start to edit this file through the management UI without even restarting Mockintosh.
One can also specify a list of interceptors to be called in <package>.<module>.<function>
format using
the --interceptor
option. The interceptor function get a mockintosh.Request
and
a mockintosh.Response
instance. Here is an example interceptor that for every requests to a path
starts with /admin
, sets the reponse status code to 403
:
import re
from mockintosh import Request, Response
def forbid_admin(req: Request, resp: Response):
if re.search(r'^\/admin.*$', req.path):
resp.status = 403
and you would specify such interceptor with a command like below:
$ mockintosh some_config.json --interceptor=mypackage.mymodule.forbid_admin
Instead of specifying a package name, you can alternatively set the PYTHONPATH
environment variable to a directory
that contains your interceptor modules like this:
$ PYTHONPATH=/some/dir mockintosh some_config.json --interceptor=mymodule.forbid_admin
Note: With interceptors, you can even omit endpoints
section from the service config. You will still get all requests
to the service into your interceptor.
The Request
object is exactly the same object defined in here
with a minor difference: Instead of accesing the dictonary elements using .<key>
, you access them using ['<key>']
e.g. request.queryString['a']
.
The Response
object consists of three fields:
resp.status
holds the HTTP status codes
e.g. 200
, 201
, 302
, 404
, etc.resp.headers
is a Python dictionary that you access and/or modify the response headers.
e.g. resp.headers['Cache-Control'] == 'no-cache'
resp.body
is usually either str
or bytes
, but can be anything that is supportedtornado.web.RequestHandler.write
str
, bytes
or dict
e.g. resp.body = 'hello world'
or resp.body = {'hello': 'world'}