Micronaut Mastery: Using Stubs For Testing

Writing tests is always a good idea when developing an application. Micronaut makes it very easy to write tests. Using the @Client annotation we can generate a client for our REST resources that uses HTTP. Starting up a Micronaut application is so fast we can run our actual application in our tests. And using dependency injection we can replace components from the production application with stubs in our tests.

Let’s show how we can use stub in our tests for an example application. In the example application we have controller ConferenceController that returns Conference objects. These objects are fetched from a simple data repository ConferenceDataRepository. When we write a test we want to replace the ConferenceDataRepository with a stub, so we can return the appropriate Conference objects for our tests.

First we take a look at the Conference class:

We add an interface that describe the functionality we expect for getting Conference objects in our application:

For our example the implementation of the ConferenceService is simple, but in a real world application the code would probably access a database to get the results:

Finally our controller to return conference data via HTTP REST that uses via dependency injection the ConferenceDataRepository implementation of the ConferenceService interface:

To add a stub for the ConferenceService in our test we must write a new implementation of the ConferenceService that is available on the test class path and not on the production code class path. In our test code directory (src/test/{java|groovy|kotlin}) we write our stub implementation. We use the @Primary annotation to instruct Micronaut to use this implementation of the ConferenceService interface. If we leave out the @Primary annotation we get an error, because we have two implementations of the interface on our classpath, ConferenceDataRepository and ConferenceServiceStub, and Micronaut doesn’t know which one to use. By using @Primary we tell Micronaut to use the stub implementation.

In our test directory we also add a declarative HTTP client to invoke the REST resource. This client is only used for testing and makes invoking the REST resource very easy:

We write a Spock specification to test our REST resource and it will use the stub code as implementation of ConferenceService:

Written with Micronaut 1.0.0.M4.

Original post

This entry was posted in Coding, Micronaut and tagged , , by mrhaki. Bookmark the permalink.

About mrhaki

My name is Hubert A. Klein Ikkink also known as mrhaki. I work at the great IT company JDriven. Here I work on projects with Groovy & Grails, Gradle and Spring. At JDriven we focus on SpringSource technologies. All colleagues want to learn new technologies, support craftmanship and are very eager to learn. This is truly a great environment to work in. You can contact me via Google+ or @mrhaki.

Leave a Reply

Your email address will not be published. Required fields are marked *