Testing

Controlling the controllers

The crud controllers

As we did in the previous example we would start the controller tests (they are named controllers but they are the equivalent of the resources in Jersey) with the basic controller than invoke the crud operations in the repositories.

The test class is: SpringExchangeRestControllerTests.java

Also like the previous example, we are going to use the same mechanism, use a framework extension, a Jumahuaca one and implement an interface that would interact with the Jumahuaca extension.

So we have the Spring extension 1):

@ExtendWith(SpringExtension.class)
@WebMvcTest(UVAExchangeController.class)

the Jumahuaca extension 2) :

@RegisterExtension
public final SpringControllerCrudExtension<UVAExchange> extension = new SpringControllerCrudExtension<UVAExchange>();

and the interface implementation 3) (by the way is the same interface of another example with a different implementation):

public class SpringExchangeRestControllerTests implements HttpWebServiceDoubleHelper<UVAExchange>{

And you don't need really much, you can see that each test case invokes an extension method and it does all the work. You will have to mock a lot but the interface will help you to know which one to override.

@async and other automagic stuff

Now it's time to test an asyncronic functionality (as we have tested in the previous example). There is no jumahuaca core interaction in these tests but it's important for the examples themself.

This one is a little different than the Dropwizard case. We add the invocation to the Scraper class in a service layer so all the controller tests are mocks and the important stuff are in the service layer.

Anyways let's start with the tests for the controller only in the test class: SpringScraperResourceTests.java.

There isn't much to review, it's a lot of mocking so we better pass to the service tests: SpringScraperServiceTests.java

In this case, it is really easier to test because we broke the Spring injection logic, we build the service object inside the test class and inject a mocked repository for the data access logic. We have integration tests (remember our custom @IntegrationTest annotation) when we do the actual scraping and unit tests where there is no http interaction.