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.