Any evidence or or experience that Spring does NOT make testing easier?

[dkarr]

It's my assumption that (properly) constructing an application using Spring makes testing of the components of that application easier than without using Spring.

I recently stated that assumption in a group meeting, and someone told me that there has been some discussion in the Spring forums that don't necessarily agree with that assumption.

Is there anyone out there who can provide any information about that, even if you don't agree with it? I went searching for any evidence or opinions in this direction, and I didn't find anything.

[wpoitras]

I taken part in a forum post which touched on this subject.

The nature of a true unit test doesn't require Spring at all. And making your objects more IoC friendly (which tends to happen when you write your code for Spring) doesn't require Spring either.

Integration testing can be made easier with Spring, depending on what kind of testing you are doing. Spring has JUnit classes for helping you wire up integration tests from XML files, as well as doing automatic rolling back of your test data, so your tests don't pollute your database. You can find out more about these in the reference manual.

I've found when talking about testing, you often get into semantics. What a "unit test" really means, what "using Spring" really means, etc.

The way I like to think about Spring is that it encourages a particular way of development. And for simple applications which only has a few service classes may not even need Spring. But once you start getting into larger sets of components, integrate a larger set of J2EE APIs, and multiple component sets, then the glue code to manage your components gets out of hand, and Spring ends up being a better solution.

[Colin Yates]

It's my assumption that (properly) constructing an application using Spring makes testing of the components of that application easier than without using Spring.

I would make the point that it is the IoC concept behind Spring that adds most benefit; not really Spring the implementation. I believe using any *non-intrusive* IoC container would result in the same benefits.

IMO IoC (not Spring) results in the following artifacts:

- a decomposed object graph containing POJOs which individually perform a single responsibility but collaborates with other objects. (core OO concept)
- a set of configuration for configuring that object graph.

The point is that each object does one thing and utilises collaborators. This allows you to mock the collaborators and unit test that object in isolation.

As for Spring itself making things easier to test; sure. I believe it is an excellent framework and has excellent utility classes, but the point I am making is that IMO the largest benefit comes from the IoC. To put it another way, if I stopped using Spring and started using another IoC framework, I would not expect to have to rewrite many unit tests. I *certainly* wouldn't expect to rewrite any business classes.... maybe one or two integration classes that extend ApplicationContextAware etc.

I recently stated that assumption in a group meeting, and someone told me that there has been some discussion in the Spring forums that don't necessarily agree with that assumption.

Not sure I agree with that point. Spring as a framework does provide utility classes to help. One consideration is that IoC usually results in a more configuration than non IoC, and you should really test that. That is an artifact of IoC though, and Spring certainly allows you to easily test your configuration. Again, it is worth identifying whether their issue is related to *Spring* or to IoC....

Is there anyone out there who can provide any information about that, even if you don't agree with it? I went searching for any evidence or opinions in this direction, and I didn't find anything.

An interest post dkarr

As I have said, IMO Spring is two things really; an IoC container and an implementation of an IoC container. I think it is an excellent, extremely well written implementation with lots of excellent layers wrapped around it (transactional support, remoting etc.) but a side effect of IoC is that of configuration. That also must be tested. Do I think testing an IoC "flavoured" implementation is harder than a non-IoC project? Absolutely not! Quite the opposite.

It would be interesting to determine how much of their concern is with IoC and how much is Spring specific.

[mucsij]

IMO IoC (not Spring) results in the following artifacts:

- a decomposed object graph containing POJOs which individually perform a single responsibility but collaborates with other objects. (core OO concept)
- a set of configuration for configuring that object graph.

I totally agree with this. In my current job they want to override class attributes for different environments (even though the implementation classes are known precisely in advance) instead of combining/packaging the right XML files. Yet can you think of any reason why you would want to mess with the class attribute of a bean (making it "dynamic")?

[dejanp]

IMO IoC (not Spring) results in the following artifacts:

- a decomposed object graph containing POJOs which individually perform a single responsibility but collaborates with other objects. (core OO concept)
- a set of configuration for configuring that object graph.

I totally agree with this. In my current job they want to override class attributes for different environments (even though the implementation classes are known precisely in advance) instead of combining/packaging the right XML files. Yet can you think of any reason why you would want to mess with the class attribute of a bean (making it "dynamic")?

Of course. How else would (otherwise completly sane) developers ever make it to The Hall Of Eternal Fame

[Colin Yates]

Of course. How else would (otherwise completly sane) developers ever make it to The Hall Of Eternal Fame

That is actually a really good, informative site

The amount of times I have looked at entries and thought "so, whats wrong with that"

[aitorelo]

I taken part in a forum post which touched on this subject.

...And for simple applications which only has a few service classes may not even need Spring.

Hello,

Do you have numbers for this assertion? I mean, we're developing an embedded system under spring and I'm not sure whether it's correct to use it or not. I still don't know if it really simplifies our code and makes it more testable or, on the contrary spring makes it less comprehensible and harder to test.

Thanks a lot!!!

[dejanp]

Hello,

Do you have numbers for this assertion? I mean, we're developing an embedded system under spring and I'm not sure whether it's correct to use it or not. I still don't know if it really simplifies our code and makes it more testable or, on the contrary spring makes it less comprehensible and harder to test.

Thanks a lot!!!

I guess you will have to show us an example of the problems you have.

[aitorelo]

First, thanks for your quick response!!!

In fact we're not having problems at all. I'm completely new to Java universe, and the problem I have is that I really don't know if adopting Spring in our solution is oversizing our application. That's why I wanted to know if you could have any figures about when to use and when not to use Spring.

Thanks again!

[wpoitras]

In fact we're not having problems at all. I'm completely new to Java universe, and the problem I have is that I really don't know if adopting Spring in our solution is oversizing our application. That's why I wanted to know if you could have any figures about when to use and when not to use Spring.

Just to be clear, there are a few levels at which people use Spring:

1. Using the Spring container. This is where components are wired together by Spring using XML.
2. For its convenience pieces. JdbcTemplate, JmsTemplate et. al. are concise ways of coding existing APIs. You can use these APIs without using the Spring container since they just use J2EE factories (i.e. javax.sql.DataSource, javax.jms.ConnectionFactory, etc)
3. AOP/Transactions. Although this doesn't require the Spring container to be configured, it often is.
4. SpringMVC. A web framework in its own right. Often configured using the Spring container.

So when people talk about "using Spring" it can mean different things.

The way I've introduced Spring into my company is to start with #2. No container or XML necessary. Just pass a DataSource to a JdbcTemplate, and you are in business.

Then I started creating decoupled components. Although I had Spring in mind, most of my components didn't contain any reference to Spring because I put the Spring specific JDBC code in DAOs and the services which used them that wasn't Spring specific in a seperate class. Classic DAO pattern.

But the project I used these components for needed 3 components, JMS, several Queue, QueueConnectionFactory, DataSource objects stored in JNDI etc. Plus I wanted the configuration properties to all be in a separate property file, not in my XML. So I needed a PropertyPlaceholderConfigurer. So what started as the #2 usage of Spring, evolved into including #1 and #3.

Back to testability: I wrote unit tests for classes which could be easily unit tested. Mostly my business components. Not Spring required. I just extended TestCase.

I wrote mostly integration tests for my DAOs, and even wrote an integration test which took my decoupled components and wired them together with a mixture of real data and mock JMS queues. The integration tests used Spring's AbstractDependencyInjectionSpringContextTests
and AbstractTransactionalSpringContextTests
to make it easier to write database backed tests.

How did Spring help? The biggest help had nothing to do with Spring.... although I originally thought it did. When I start to write decoupled applications to work well with Spring I find it was the design patterns and practices that Spring encourages that helped: DAO, Strategy, Template patterns, domain-driven design, test-driven design. Where Spring fits in, it helps me glue my application together. I could do it without Spring, but I found Spring makes it easier.

I'm sorry, I don't think its possible to supply you with good numbers of when to use and not use Spring. Its more of a qualitative answer. You should start with an application architecture that has nothing to do with Spring, and then see if Spring will help you. But that can also depend on the roadmap for your system. If you think you'll be adding components in the future, getting a start with Spring on a small application may be worth it. If you are only going to have 3 components that you considered using Spring for, but uses no AOP, no property substitution, no JNDI, etc you might be better off using a simple factory to wire your components rather than involve Spring.