Unit tests are very handy. They run fast and it is possible to execute hundreds or even thousands of them very often during development (especially useful when using TDD). Nevertheless from time to time we want to test the correctness of a part of an IoC container configuration and check how those components works together when managed by an IoC context. In this tutorial I will show how to do it in a convenient way.
The easiest solution could be to set up the whole “production” IoC context. Unfortunately depending on the size of a project it can take some time (long minutes) and in addition that configuration is likely to connect to external resources like a database or a message queue which makes restriction where those tests will be able to run. What can we do to fix it?
Very often to test interactions between selected components it is not needed to make the full featured integration tests. We can use two useful techniques together: limiting context scope (?) and mocking. The idea is to set up only needed components. This can be achieved by separate a minimal Spring configuration file using in tests (possible reusing some of existing production files). However very often there is a problem with direct dependencies which behaviors (?) are not needed in our tests, but are required to set up our beans. Doesn’t it look familiar to the situation meet also in unit tests? Mocks (and Mockito) to the rescue.
Our mocks have to be put into Spring context to be able to inject into other beans created by Spring. While it can be done using pure Spring mechanisms, there is a library which makes it much easier – Springockito written by Jakub Janczak.
Note. Pure unit tests are generally much better choice. Tests using IoC context should be only used when we really need to test behaviors within a context.
To start working with Springockito it is required to add its JAR to the project dependencies. Using Maven it could be:
<dependency>
<groupId>org.kubek2k</groupId>
<artifactId>springockito</artifactId>
<version>1.0.4</version>
<scope>test</scope>
</dependency>
With Gradle:
testCompile "org.kubek2k:springockito:1.0.4"
(change 1.0.4 to the latest released version of Springockito)
Note. The following examples are simplified to does not introduce unneeded distractions. They do not have a context configuration which is worth to test and it would be easier to use pure unit tests (without a Spring context).
Let’s take following configuration where plantWaterer object requires waterSource and waterScheduler beans:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
<bean id="plantWaterer" class="info.solidsoft.refcard.mockito.PlantWaterer">
<constructor-arg name="waterSource" ref="waterSource"/>
<constructor-arg name="waterScheduler" ref="waterScheduler"/>
</bean>
<bean id="waterSource" class="info.solidsoft.refcard.mockito.RiverWaterSource">
<constructor-arg ref="smallRiver"/>
</bean>
<bean id="waterScheduler" class="info.solidsoft.refcard.mockito.WaterScheduler"/>
</beans>
RiverWaterSource relies on an external resource which could be problematic during tests. To override it following configuration (with the additional namespace mockito) could be used.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:mockito="http://www.mockito.org/spring/mockito"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.mockito.org/spring/mockito https://bitbucket.org/kubek2k/springockito/raw/tip/springockito/src/main/resources/spring/mockito.xsd">
<mockito:mock id="waterSource" class="info.solidsoft.refcard.mockito.WaterSource"/>
</beans>
Make a note that there is even no try to create the original bean. This is very useful in a situation where for example DAO would like to make a connection to a database during start up (which could take some time and is very fragile).
With Springockito it is also very easy to make a spy of existing Spring bean and inject it into another bean instead of the original bean for example to verify made interactions.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:mockito="http://www.mockito.org/spring/mockito"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.mockito.org/spring/mockito https://bitbucket.org/kubek2k/springockito/raw/tip/springockito/src/main/resources/spring/mockito.xsd">
<mockito:spy beanName="waterSource"/>
</beans>
Mocks and spies created with a help of Springockito are just like “normal” mocks/spies which can be stubbed and verified. However there are two important differences. The instance of a mock/spy is created by Spring when a context is set up (in opposite to manual call Mockito.mock/spy() or using @Mock/@Spy annotation), so the easiest way to obtain it is to make an injection into our tests class (by name or by type).
@ContextConfiguration({<<configuration-files>>})
public class MockInjectionSpringockitoTest extends AbstractTestNGSpringContextTests {
@Autowired
private PlantWaterer plantWaterer;
@Autowired //it is safe - Springockito hid the original WaterSource bean
private WaterSource waterSourceSpy;
@Test
public void shouldSpyInjectedObject() {
//given - mocks/spies are already created, can be stubbed here
//when
plantWaterer.waterPlants();
//then
verify(waterSourceSpy).startWaterFlow();
}
}
The seconds important difference is also related to the fact that a mock/spy is created with a context and the same instance is hold until the context shutdown. It can span across many tests or even test classes. It is important to properly reset/initialize mocks/spies manually before every test to avoid an impact of the operations done in previously executed tests. The issue has been already reported and hopefully will be resolved in the further Springockito versions.
Btw, in case of the following error:
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.mockito.org/spring/mockito]
Offending resource: class path resource [yourSpringConfig.xml]
at org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:68)
at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:85)
(...)
make sure the Springockito JAR has been successfully added as a project dependency.
In case you prefer annotations over XML Springockito has also something for you. This is a version of Springockito which allow to do similar things, but directly in your test code.
To use it in a project it is required to add an springockito-annatations.jar to your project dependencies.
With Maven:
<dependency>
<groupId>org.kubek2k</groupId>
<artifactId>springockito-annotations</artifactId>
<version>1.0.2</version>
</dependency>
With Gradle:
testCompile "org.kubek2k:springockito-annotations:1.0.2"
(change 1.0.2 to the latest released version of springockito-annotation – the numeration is not synchronized with springockito – it is an independent jar (as of 1.0.2))
@ContextConfiguration(loader = SpringockitoContextLoader.class, locations = {<<the-base-configuration-file>>})
public class MockInjectionSpringockitoTest extends AbstractTestNGSpringContextTests {
@Autowired
private PlantWaterer plantWaterer;
@WrapWithSpy
@Autowired //to inject a spy into this field to make a verification
private WaterSource waterSource; //spy
@ReplaceWithMock //just replace the original bean with a mock, will be null
//it won't be stubbed - no need to inject
private WateringScheduler wateringScheduler; //mock
@Test
public void shouldSpyInjectedObject() {
//given - mocks/spies are already created, can be stubbed here
//when
plantWaterer.waterPlants();
//then
verify(waterSource).startWaterFlow();
}
}
The trick here is to use a custom Spring context loader which checks (by name) if there is any bean which should be replaced with a mock or wrapped with a spy.
The code above causes waterSource bean defined in a configuration file to be wrapped with a spy and wateringScheduler bean to be replaced with a mock (the original wateringScheduler bean will not be created at all). They are both injected into plantWaterer. @ReplaceWithMock and @WrapWithSpy annotations are used only by Springockito to detect which beans should be replaced/wrapped. To get an instance of a mock/spy (to stub it or verify behavior) it is needed to use also an appropriate annotation (@Autowired, @Resource or @Inject) – see waterSource in the previous listing.
There is a limitation which force to use the same field name as a bean which should be replaced/wrapped. It should be fixed in the future.
This post is the second part of the series Beyond the Mockito refcard extending recently released my Mockito reference card.
. The downside of using such tool is a limited way how it could be exported to some neutral format. The picture below contains the whole map, but without code snippets.
