Spring beans redefinition in unit test environment

Question

We are using Spring for my application purposes, and Spring Testing framework for unit tests. We have a small problem though: the application code loads a Spring application

Answer 1

There are some very complicated and powerful solutions listed here.

But there is a FAR, FAR simpler way to accomplish what Stas has asked, which doesn't involve modifying anything other than one line of code in the test method. It works for unit tests and Spring integration tests alike, for autowired dependencies, private and protected fields.

Here it is:

junitx.util.PrivateAccessor.setField(testSubject, "fieldName", mockObject);

Answer 2

See this tutorial with @InjectedMock annotation

It saved me a lot of time. You just use

@Mock
SomeClass mockedSomeClass

@InjectMock
ClassUsingSomeClass service

@Before
public void setUp() {
    MockitoAnnotations.initMocks(this);
}

and all your problems are solved. Mockito will replace the spring dependency injection with a mock. I just used it myself and it works great.

Answer 3

I don't have the reputation points to pile on duffymo's answer, but I just wanted to chime in and say his was the "right" answer for me.

Instantiate a FileSystemXmlApplicationContext in your unit test's setup with a custom applicationContext.xml. In that custom xml, at the top, do an as duffymo indicates. Then declare your mock beans, non-JNDI data sources, etc, that will override the id's declared in the import.

Worked like a dream for me.

Answer 4

Since the OP this has come along: Springockito

Answer 5

You can use the import feature in your test app context to load in the prod beans and override the ones you want. For example, my prod data source is usually acquired via JNDI lookup, but when I test I use a DriverManager data source so I don't have to start the app server to test.

Answer 6

Easy. You use a custom application context for your unit tests, or you don't use one at all and you manually create and inject your beans.

It sounds to me like your testing might be a bit too broad. Unit testing is about testing, well, units. A Spring bean is a pretty good example of a unit. You shouldn't need an entire application context for that. I find that if your unit testing is so high-level that you need hundreds of beans, database connections etc., you have a really fragile unit test that is going to break on the very next change, will be hard to maintain and really isn't adding a lot of value.