In the bigger projects I've worked on, testing the components of the system is a key point. When multiple teams are working on a project and each create services in there functional domain, you want the place the responsibility of these services with that software development team (SDT). Let's talk in terms of a assembly line. If one team needs to integrate with a service of another team it should not have to wait for the other team to finish implementing the service. Also you don't want that the team that needs to integrate with a service more down the assembly line is responsible for the correct delivery at the end of the assembly line. Each team should only be responsible for there functional boundary.
This scenario also played at my current project. The project grew and grew and also more teams were added. The integration team had taken the responsibility for testing the whole assembly line and with the growth this responsibility and quality could not be guaranteed. The solution architects then decided to lay the responsibility of testing the services at the team that created them and that a smoke test would be done later on a integration environment. Each team from now on is only responsible for testing the chain of services they create(d) and mock all other services.
The integration SDT took the responsibility to come up with a way to accomplice this. The SDT was giving the following requirements.
- Functional testing of the boundaries of the domain of a SDT.
- Implementation should be transparent to all environments, one size fits all.
- Tooling should be useful for both Unit Testing and Integration Testing.
- Tooling should be easy to use and should not be unnecessarily time consuming to set up.
- It should be possible to run tests through a build server (e.g. Hudson)
After researching available tools, SoapUI, WireMock, JAX-WS (Java), MockServer and Moco, showed that MockServer most satisfies the requirements for boundary testing.
What is MockServer
With MockServer (created by James D. Bloom) you can easily mock response messages from each system which you integrate with via HTTP(S).
- Mocking of any HTTP(S) response matched to the received request.
- Proxing to dynamically route messages.
- Recording requests and responses to analyse how a system behaves.
- Verifying which requests and responses have been sent as part of a test.
A few useful scenarios to use MockServer:
- Easy and effective testing of HTTP(S) dependencies (SOAP, REST).
- Isolating the system / module that needs to be tested (no dependencies).
- Avoid sharing data between tests that is difficult to manage and maintain and risks tests infecting each other.
De-coupling during development:
- Start working against a service API before the service is available.
- Isolating development teams particularly critical during the first phase of development as the APIs / services are highly unstable and volatile.
Read the full blog on the AMIS Technology Blog