At my work we have recently put together a couple of test suites written in Java to test some RESTful APIs we built. Our Services could invoke other RESTful APIs they depend on. We split it into two suites.
- Suite 1 – Testing each service in isolation
- Mock any peer services the API depends on using restito. Other alternatives include rest-driver, wiremock and betamax.
- Tests the service we are testing and the mocks all run in a single JVM
- Launches the service in Jetty
I would definitely recommend doing this. It has worked really well for us. The main advantages are:
- Peer services are mocked, so you needn’t perform any complicated data setup. Before each test you simply use restito to define how you want peer services to behave, just like you would with classes in unit tests with Mockito.
- You can ask the mocked peer services if they were called. You can’t do these asserts as easily with real peer services.
- The suite is super fast as mocked services serve pre-canned in-memory responses. So we can get good coverage without the suite taking an age to run.
- The suite is reliable and repeatable as its isolated in it’s own JVM, so no need to worry about other suites/people mucking about with an shared environment at the same time the suite is running and causing tests to fail.
- Suite 2 – Full End to End
- Suite runs against a full environment deployed across several machines
- API deployed on Tomcat in environment
- Peer services are real ‘as live’ full deployments
This suite requires us to do data set up in peer services which means tests generally take more time to write. As much as possible we use REST clients to do data set up in peer services.
Tests in this suite usually take longer to write, so we put most of our coverage in Suite 1. That being said there is still clear value in this suite as our mocks in Suite 1 may not be behaving quite like the real services.