Chapter 9. Integration Testing with Mockito and DI Frameworks

In this chapter, we will cover the following recipes:

  • Injecting test doubles instead of beans using Spring's code configuration
  • Injecting test doubles instead of beans using Spring's XML configuration
  • Injecting test doubles instead of beans using Springockito
  • Injecting test doubles instead of beans with Guice
  • Injecting test doubles instead of beans with Guice using Jukito

Introduction

Dependency Injection (DI) and Inversion of Control (IOC) are the terms that you have to understand to get the most out of the contents of this chapter (for more information, refer to Martin Fowler's article at http://martinfowler.com/articles/injection.html). We will not elaborate on the importance of those two concepts here. We will focus on using them together with Mockito and two Mockito based tools. We'll do that to inject test doubles instead of real beans in our application.

The idea behind integration tests with DI frameworks is that we want the application to have its dependencies already instantiated and injected. We may have fragments of code where we want to send or retrieve data via a web service or a system where a connection to another server is necessary. When performing integration testing, we do not want to have such connections set. Since integration tests are run from our local machines, we want to limit the need for configuring access to those external servers. You may also want to verify that a particular method was executed on a component. That is why we would have to either stub those connections or set up a test double for our external data provider (check out projects such as Moco at https://github.com/dreamhead/moco or WireMock at http://wiremock.org/ for examples of HTTP server mocks). It all depends on the context, but in my opinion the latter approach gives you more reliable integration with external systems. For example, if it's a HTTP server mock, then you will send a real request and receive a real response—you will be able to test how your production code really works.

In the following recipes, we will focus on the first approach—we will create mocks of our dependencies in order to stub the call and to verify that we made that call only once (let's assume that we pay a lot of money for each call, thus we want to be sure that those method executions do not happen too often).

We will play around with two most famous and widely used DI frameworks—Spring and Guice. First, we will try to set up test doubles just by using internals of either of those frameworks and then we will check out two libraries. Springockito (https://bitbucket.org/kubek2k/springockito/wiki/Home) for Spring (http://projects.spring.io/spring-framework/) and Jukito (https://github.com/ArcBees/Jukito) for Guice (https://code.google.com/p/google-guice/). This chapter assumes that you already have either Spring or Guice on your classpath, so please consult the respective websites for more information. The whole setup (Maven and Gradle) is also present in the Mockito Cookbook's Github repository (https://github.com/marcingrzejszczak/mockito-cookbook).

All of the examples in this recipe will deal with transferring tax for a person via a web service. Since we don't want to send any real data, we will mock the web service, stub the method execution, and verify whether the call took place only once (because we pay plenty of money for each call). We will further check whether the message sending took place successfully.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.118.32.222