Chapter 4. Component-testing microservices

You’ve learned about the basic component makeup of a microservice and various basic testing techniques. Now it’s time to dig a little deeper into what style of test best suits each component, and how you should implement those tests.

Component tests should be designed to verify the functionality of and between a microservice’s internal modules, with one exception: the external public-facing resource component. You want to be sure the public-facing service is accessible to the world in the way that you’ve planned, so you’ll need to define a client-based test that ensures this is the case. A component test shouldn’t cross a remote boundary outside the local machine.

You need a good mixture of solitary and sociable tests to cover all the internal interactions of the microservice under test. Tests should use doubles to replace interactions that would normally collaborate with external resources.

4.1. The Arquillian test framework

4.2. Introducing the @RunWith(Arquillian.class) annotation

4.3. The ShrinkWrap utility class

4.4. Write once and reuse your code

4.5. Build-script modifications

4.6. Overriding the default Arquillian configuration

4.7. Using Arquillian REST extensions

4.8. Testing Spring applications using Arquillian

4.9. More-complex Arquillian test examples

Exercises

Summary