One of the Spring killer-features is an in-container integration testing. While EJB lacked this functionality for many years, Spring from the very beginning allowed you to test the full stack.

Database is the problematic part. First you need to use in-memory self-contained DB to decouple your tests from an external database. Spring helps with this to a great degree, especially now with profiles and embedded database support. The second problem is more subtle. While typical Spring application is almost completely stateless, database is inherently stateful. This complicates integration testing since the very first principle of writing tests is that they should be independent on each other and repeatable. If one test writes something to the database, another test may fail; also the same test may fail on subsequent call due to database changes.

Obviously Spring handles this problem as well with a very neat trick: prior to running every test Spring starts a new transaction. The whole test runs within the same transaction which is... rolled back at the end. This means all the changes made during the test are visible in the database just like if they were persisted. However rollback after every test wipes out all the changes and the next test works on a clean and fresh database.

Unfortunately this is not yet another article about Spring integration testing advantages. I think I have written hundreds if not thousands of such tests and I truly appreciate the transparent support Spring framework gives. But I also came across numerous quirks and inconsistencies introduces by this comfortable feature. To make matters worse, very often so-called transactional tests are actually hiding errors convincing the developer that the software works, while it fails after deployment!

Read the rest of the article at the following URL:

Java Code Geeks: Spring Pitfalls: Transactional tests considered harmful

First you need to use in-memory self-contained DB to decouple your tests from an external database.

So you would have to re-create the whole database structure 'in-memory' and fill it with appropriate test data to work around Spring's flawed DI design?! I have never seen this done. Spring applications remain untested (by UnitTests) because their DI-based design is untestable or, at least, only testable with prohibitively expensive setup. It's time to debunk the numerous myths that surround this complexity generator "framework". 

Please don't make noise with a such pityfull title.

It seems obvious you never use it in the right way.

Compare to other options, spring brings nice integration testability. Ok now there's JEE6 with its embedded container (exactly like spring ... wow ... is it a pure coincidence).

You propose to denounce the myth around spring testability. Be my guest, just do it. Don't bother us with your !!!!!!! at the end of a title.

You are completely missing the point. Any framework that fosters untestability is flawed. Any framework that requires 'in-memory databases' or tedious mock-object setups for testing application logic is flawed.

There's no absolutely reason to repeat Spring's design anti-patterns in modern JEE application servers. 

I'm not missing the point. There's no need of an embedded DB. It just support it or you can use a file backed one. Spring does its best to adapt to your situation (as usual).

Please be by guest to demonstate I'm wrong (with come code this time and no fuzzy words).

Do you work for JBosss ? :))

Uh ?

Why are you lying like this ? I've tested DAO dozen times with spring and an embedded DB. It is explain in the doc. Seriously, you need to learn more.

 

Spring applications remain untested (by UnitTests) because their DI-based design is untestable or, at least, only testable with prohibitively expensive setup. It's time to debunk the numerous myths that surround this complexity generator "framework". 

Please do. Lay out the most convincing specific examples which prove that claim.

I'm working on a spring-backed application wich is both unit- and integration-tested heavily, and I can't see how your statement can be true.

It seems all your examples are either to do with quirks in Hibernate (and lords knows there are plenty of those...) or concurrency issues in multithreaded scenarios, which are unpredictable by default. What has any of this got to do with Spring?

From what I understand, the author was caught by surprise by a few things:

- Test cases of a class marked as @Transactional are executed in transaction

- Default behaviour is to roll back transaction after test case execution

- Mixture of threading and transactions may yield non-obvious results

To me, it is an indication that person just starts using spring and transactional testing. Its ok if he prefers to learn things by discovery rather than from docs. Just takes more attempts.

And I pretty sure you also notice that he never checks the state of its database (typically with a jdbcTemplate), but through its attached/detached entities.