MockServer

Short description: Open source mocking framework for HTTP and HTTPS

MockServer is an open source mocking framework for HTTP and HTTPS released under the Apache License. MockServer is designed to simplify integration testing, by mocking HTTP and HTTPS system such as a web service or web site, and to decouple development teams, by allowing a team to develop against a service that is not complete or is unstable.

Simplify testing

MockServer simplifies automated testing and promotes best practices by improving the isolation of the system under test, simplifying test scenarios and improving encapsulation and separation of concerns in tests, as follows:

• Mocking dependent systems is an effective mechanism to isolate the system under test to ensure tests run reliably and only fail when there is a genuine error, this avoids tests failing due to irrelevant external changes such as network failure or a server being rebooted / redeployed.
• In addition to test isolation mocking dependent system also allows the full range of responses and scenarios to be tested without having to set up and manage a complex test infrastructure. For example, increased response delay or dropped connections can increase as load increases on a dependant system. To simulate these types of performance related degradation can be extremely difficult without generating a large volume of traffic. If the dependent system is mocked the mock can control the exact response delay or any other characteristics of each response.
• A common anti-pattern for automated tests is to record and replay real dependent service responses. These recordings are typically complex and shared between multiple tests. This, however, introduces unnecessary coupling between tests and breaks the Single responsibility principle, which, states that every context (class, function, variable, etc.) should define a single responsibility, and that responsibility should be entirely encapsulated by the context. Record and replay solutions also break down when the response changes. For example, if a bookshop service is mocked by recording a response containing a list of 50 books, when the format for a book changes then the recorded response must be updated in 50 places. If a new response is recorded with the new format, most likely, the test assertions will need to be updated. In addition record and replay approaches hide the data being used in the test from the test code and therefore break encapsulation and separation of concerns. MockServer simplifies the mocking of responses for dependent systems by providing a simple API and client in multiple languages. Each test can then independently encapsulate the data and logic used for mock services, ensuring each test runs independently. In addition such an approach also reduces the time for a suite of test to complete because tests can run in parallel and do not share data.

Decoupling development teams

MockServer decouple development teams, by allow a team to develop against a service that is not complete or is unstable, as follows:

• If an API or service is not yet fully developed MockServer can be used to mock the API allowing any team who is using the service to start work without being delayed. Mocking an API or service during development of an application can often increase the cost of integration because the longer the delay before systems are fully integrated the more expensive it can be to refactor or reverse incorrect design decisions with prevent integration. However, often two systems that integrate must be built parallel due to financial or time pressure. If an application is being built against an unstable and unreliable interface this can lead to the development and testing being frequently blocked. Mocking the unstable interface can provide more control over when and how the integration is performed to reduce the overall disruption and cost.
• Mocking a service also allows development teams to isolated from an unstable, unreliable or volatile web service. This is particularly critical during the initial development phases when the APIs / services are changing frequently and cause development and testing to be blocked.

Features

The main features supported are:

• return a specific response when a request matching an expectation has been received
• return a response dynamically when a request matching an expectation has been received
• execute a callback (in Java) when a request matching an expectation has been received
• verify a requests has been sent a specific number of times
• verify a sequence of requests have been sent in a specific order
• record requests and responses to analyse how a system interacts with external dependencies

Technology

MockServer is built using Netty and is written in Java. It runs on as an embedded server on a separate Thread or as a standalone Java Virtual Machine.

MockServer can be used in several ways:

• via an Apache Maven Plugin as part of an Apache Maven build cycle
• programmatically via an API in an @Before or @After method in a JUnit or TestNG test
• using a JUnit @Rule via a @Rule annotated field in a JUnit test
• from the command line as a stand-alone process in a test environment
• as a Docker container in any Docker-enabled environment
• as a Vert.x module as part of an existing Vert.x environment
• as a deployable WAR to an existing web server
• as a grunt.js plugin as part of a grunt.js build cycle
• as a Node.js (npm) module from any Node.js code
• as a PHP Behat (computer science) context for functional testing

MockServer is available as:

• a stand-alone Netty web server that is fully self-contained
• a deployable WAR that runs on any Java Enterprise Edition web server
• a fully encapsulated Docker container
• a Vert.x module that runs on a Vert.x

See also

• Service virtualization
• Comparison of API simulation tools
• Mock object
• Software testing
• Integration testing