Mimock is a utility to setup mocks for REST API endpoints to mimic the response of the actual endpoints. This tool will be helpful for testing UI applications locally or in CI/CD pipelines. Mimock follows an interceptor-based pattern which enables the users to setup and use the mocks in real time without any need for re-deployment.
This project is geared towards both open-source and enterprise applications that offer REST API based solutions. Mimock functions as a faster, easier to set up and automate testing utility tool that can be easily integrated into the deliverables pipeline of various projects.
Mimock is published under the open-source Apache-2.0 license.
Some of the key features offered by the Mimock are as follows
Mimock is a Java based application, hence it requires
Java 8+ to run the application.
There are two variants of docker images available for mimock
The docker image with the
latest tag includes all the required artifacts to use mimock with no additional setup. The container can be directly started to use the application and this variant is best suited for local developments workflows.
docker pull mimock/mimock:latest docker run --name mimock -d -p <destination port>:8080 mimock/mimock:latest # Once the container is ready, mimock will be available on https://localhost:<destination port>
The slim variant includes only the jar file of the application. The database and keystore setup need to be done by the user, and the required environment variables must be passed to run the container. This image variant is intended for a highly customized setup
docker pull mimock/mimock:slim # Ensure that PostgreSQL Database is setup before starting the container # The Dockerfile.pg has a minimal setup for spinning up a DB container docker run --name mimock-slim -d -p <destination port>:8080 \ -e MIMOCK_LOG_LEVEL=INFO \ -e MIMOCK_KEYSTORE_ENABLE=false \ -e MIMOCK_DB_SCHEMA=mimock_schema_dev \ -e MIMOCK_DB_URL=jdbc:postgresql://mimock-db:5432/mimock_db \ -e MIMOCK_DB_USER=mimock \ -e MIMOCK_DB_PASSWORD=<db password> \ -e MIMOCK_JWT_EXPIRY_DURATION=24h \ -e MIMOCK_JWT_SECRET=<key with 32 characters> \ -e MIMOCK_CORS_ORIGINS=http://localhost:3001 \ -e MIMOCK_CORS_METHODS=GET,POST,PUT,DELETE,OPTIONS \ -e MIMOCK_CORS_ALLOWED_HEADERS=Authorization,Content-Type,X-Requested-With,Accept,X-XSRF-TOKEN \ -e MIMOCK_CORS_EXPOSED_HEADERS=Cache-Control,Content-Language,Content-Length,Content-Type,Content-Disposition,Expires,Last-Modified,Pragma \ mimock/mimock:slim # Once the container is ready, mimock will be available on http://localhost:<destination port>
If docker-compose is preferred, then the docker-compose.yml file includes the services to setup the DB and the app container.
docker-compose up -d # Destination port can be updated to the desired value if another service is running on port 8080 # ports: # - "<desired port>:8080" # Mimock will be available on https://localhost:8080
Mimock follows a role based user management system and the services can be accessed only by an authenticated user. To handle initial application setup, a default ADMIN user is created, which can be used to create other users.
More details about user roles are available here
It is recommended to create a new ADMIN user and then use that to disable the default
Ensure PostgreSQL is setup with a user and a schema for mimock to automatically complete the required table setup.
mimock.properties - The bundle includes the properties file with the required configuration to start mimock. Check the config file and ensure the custom config items are properly setup.
Download the platform-specific bundle from [above]. (#download-options) and run the following command to start mimock.
java -jar mimock.jar --spring.config.location=./mimock.properties
The mimock-k8s directory has aset of kubernetes manifest files to give an idea of how to setup mimock within a k8s cluster.
A demo project is available on Github, which simulates a scenario of running an UI automation test by setting up mocks using mimock. The project is a simple web application which relies on two endpoints, one for a
json response and the other for a
webp image. The mocks for both the endpoints are setup within the workflow and the UI automation script captures the results as snapshots, and publishes the same to the workflow summary