Thomas Sundberg

May 16, 2010

Dependency injection

Filed under: Java, Teaching — Tags: , , , , , , , , , — Thomas Sundberg @ 20:33

This post has been migrated to

Dependency injection is invaluable when building software. Decoupling components means that it is possible to test
them independently.

A popular tool for dependency injection is Spring. Spring may, however, be overwhelming; it is a large toolbox that
may be used for a variety of different purposes.

I will show a minimal configuration that may be used to test a Java class created as a bean in a JUnit test case. We
will only look at how to get the testing up and running.

Building software today may be done using very powerful building tools. One popular, and powerful tool, is Maven.
Maven will assist you to download the needed dependencies, to compile your code, to run tests and to package the
result in a jar.

Project structure

A directory layout:

    root -- src -- main -- java -- se -- sigma -- experinemtal --
         +- test -- main -- java -- se -- sigma -- experinemtal --
         |         +- resources -- applicationContextTest.xml
         + pom.xml

This is a standard Maven directory layout. We will be working with four files:

  • pom.xml – The Maven project definition
  • – A production class to be tested
  • – A test class that will get the production class injected by Spring
  • applicationContextTest.xml – The definition that defines the bean that will be injected into the test

Maven project definition

Let’s start with the Maven project definition file, pom.xml

<project xmlns="" xmlns:xsi=""
    <name>Smallest possible Spring and Maven example</name>

We have a header defining the project and we have a dependency part that defines the dependencies that we need for
this example.

The header tells us a little bit about the project, the name of the artifact created and the format.

The dependency part is the interesting part. Here we define three dependencies.

  • junit:junit.4.8.1 – is needed to create a JUnit test that will verify that the injected bean is available
  • org.springframework:spring-test:2.5.6 – is needed, since we want Spring to handle the dependency injection for
  • org.springframework:spring-context:2.5.6 – is needed so Spring can create the necessary context to create the

The test code

This is where the interesting parts will happen today. We have a test class that only verifies that an
injected class is set.

package se.sigma.experimental;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

import static junit.framework.Assert.assertNotNull;

@ContextConfiguration(locations = {
public class PojoTest {
    private Pojo pojo;

    public void verifyAutowiring() {
        assertNotNull("Expected pojo to be set", pojo);

The interesting magic is the test runner @RunWith(SpringJUnit4ClassRunner.class) annotation and the @Autowired

If we run the test with the Spring JUnit runner, it will parse the applicationContext specified with the
@ContextConfiguration annotation. The only thing that we want to make sure is that the applicationContextTest.xml is
available in the classpath. It is stored in ./src/test/resources so Maven will automatically add it to the test

The @Autowired annotation tells us that we are expecting someone to inject an instance of se.sigma.experimental.Pojo
in some magic way. It will be injected by Spring when we run the test, since we are using the
SpringJUnit4ClassRunner to run our test.

The only thing missing now is the connection between the Production code and the Test code. It is defined in the
applicationContextTest.xml file.

The production code

To be able to test any production code, we need some code. A POJO (Plain Old Java Object) will be sufficient
in this example.

The simplest possible POJO may be:

package se.sigma.experimental;

public class Pojo {

It doesn’t do anything. We have a minimum of stuff that can fail.

Spring configuration

The glue needed to connect our test with our production code is provided in applicationContextTest.xml

<?xml version="1.0"  encoding="ISO-8859-1"?>
<beans xmlns=""

    <bean id="pojo" class="se.sigma.experimental.Pojo"/>


This is a small configuration, almost nothing that can go wrong. All we do is define a bean called pojo. This
bean is based on the class se.sigma.experimental.Pojo. Instances of it will be injected into all classes that need
it. Classes may specify that they need our Pojo bean either by using the @Autowired annotation or by defining them
as beans in the application context.

Build and test

Finally, we want to build and run our test so we can verify that it really works.

mvn clean install

Maven will download the dependencies it needs, compile, run the test and finally package the result.


Dependency injection is a powerful tool to break dependencies. Without a too tight coupling between all classes in
the system we will be able to test the in smaller pieces and inject mock or fake object where we need. This will
allow us to build and test our system using tools like Test Driven Development, TDD.

Spring is magic, but not so magic.

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at

%d bloggers like this: