|
|
Testing
As you've probably gathered, I and the other Spring developers are firm
believers in the importance of comprehensive unit testing. We believe that
it's essential that frameworks are thoroughly unit tested, and that a prime
goal of framework design should be to make applications built on the framework
easy to unit test.
Spring itself has an excellent unit test suite. We've found the benefits of
test first development to be very real on this project. For example, it has
made working as an internationally distributed team extremely efficient, and
users comment that CVS snapshots tend to be stable and safe to use.
We believe that applications built on Spring are very easy to test, for the
following reasons:
-
IoC facilitates unit testing
-
Applications don't contain plumbing code directly using J2EE services such
as JNDI, which is typically hard to test
-
Spring bean factories or contexts can be set up outside a container
The ability to set up a Spring bean factory outside a container offers
interesting options for the development process. In several web application
projects using Spring, work has started by defining the business interfaces
and integration testing their implementation outside a web container. Only
after business functionality is substantially complete is a thin layer added
to provide a web interface.
Since Spring 1.1.1, Spring has provided powerful and unique support for a form
of integration testing outside the deployed environment. This is not intended
as a substitute for unit testing or testing against the deployed environment.
However, it can significantly improve productivity.
The org.springframework.test package provides valuable superclasses for integration tests using a
Spring container, but not dependent on an application server or other deployed
environment. Such tests can run in JUnit--even in an IDE--without any special
deployment step. They will be slower to run than unit tests, but much faster to
run than Cactus tests or remote tests relying on deployment to an application
server. Typically it is possible to run hundreds of tests hitting a development
database--usually not an embedded database, but the product used in
production--within seconds, rather than minutes or hours. Such tests can quickly
verify correct wiring of your Spring contexts, and data access using JDBC or ORM
tool, such as correctness of SQL statements. For example, you can test your DAO
implementation classes.
The enabling functionality in the org.springframework.test package includes:
-
The ability to populate JUnit test cases via Dependency Injection. This
makes it possible to reuse Spring XML configuration when testing, and
eliminates the need for custom setup code for tests.
-
The ability to cache container configuration between test cases, which
greatly increases performance where slow-to-initialize resources such as
JDBC connection pools or Hibernate SessionFactories are concerned.
-
Infrastructure to create a transaction around each test method and roll it
back at the conclusion of the test by default. This makes it possible for
tests to perform any kind of data access without worrying about the effect
on the environments of other tests. In my experience across several complex
projects using this functionality, the productivity and speed gain of such a
rollback-based approach is very significant.
|