Integration testing - Java-Springs

Overview

It is important to be able to perform some integration testing without requiring deployment to your application server or connecting to other enterprise infrastructure. This will enable you to test things such as:

• The correct wiring of your Spring IoC container contexts.
• Data access using JDBC or an ORM tool. This would include such things as the correctness of SQL statements, Hibernate queries, JPA entity mappings, etc.

The Spring Frame work provides first class support for integration testing in the spring-test module.The name of the actual jar file might include the release version and might also be in the long org. spring frame work. test form, depending on where you got it from.This library includes them org. spring frame work. test package, which contains valuable classes for integration testing with a Spring container.This testing does not rely on an application server or other deployment environment. Such tests are slower to run than unit tests but much faster than the equivalent Cactus tests or remote tests that rely on deployment to an application server.

In Spring 2.5 and later, unit and integration testing support is provided in the form of the annotation-driven Spring Test Context Frame work.The Test Context Framework is agnostic of the actual testing framework in use, thus allowing instrumentation of tests in various environments including JUnit, TestNG, and so on.

Legacy JUnit 3.8 class hierarchy is deprecated

As of Spring 3.0, the legacy JUnit 3.8 base class hierarchy (for example,Abstract Dependency Injection Spring Context Tests, Abstract Transactional Data Source Spring Context Tests, etc.) is officially deprecated and will be removed in a later release. Migrate this code to the Spring Test Context Frame work.

Goals of integration testing

Spring's integration testing support has the following goals:

• Spring IoC container caching between test execution.
• Dependency Injection of test fixture instances.
• Transaction management appropriate to integration testing.
• Spring-specific support classes that are useful in writing integration tests.

Context management and caching

The Spring Test Context Frame work provides consistent loading of Spring Application Contexts and caching of those contexts. Support for the caching of loaded contexts is important, because startup time can become an issue - not because of the overhead of Spring itself, but because the objects instantiated by the Spring container take time to instantiate. For example, a project with 50 to 100 Hibernate mapping files might take 10 to 20 seconds to load the mapping files, and incurring that cost before running every test in every test fixture leads to slower overall test runs that could reduce productivity.

Test classes provide an array containing the resource locations of XML configuration metadata – typically in the classpath - that is used to configure the application. These locations are the same as or similar to the list of configuration locations specified in web.xml or other deployment configuration files.

By default, once loaded, the configured ApplicationContext is reused for each test.Thus the setup cost is incurred only once (per test fixture), and subsequent test execution is much faster. In the unlikely case that a test corrupts the application context and requires reloading -- for example, by changing a bean definition or the state of an application object-- a Spring testing support mechanism causes the test fixture to reload the configurations and rebuilds the application context before executing the next test.

Dependency Injection of test fixtures

When the Test Context frame work loads your application context, it can optionally configure instances of your test classes via Dependency Injection.This provides a convenient mechanism for setting up test fixtures using precon figured beans from your application context.A strong benefit here is that you can reuse application contexts across various testing scenarios (e.g., for configuring Spring-managed object graphs, transactional proxies, DataSources, etc.), thus avoiding the need to duplicate complex test fixture set up for individual test cases.

As an example, consider the scenario where we have a class, Hibernate Title Dao, that performs data access logic for say, the Title domain object. We want to write integration tests that test all of the following areas:

• The Spring configuration: basically, is everything related to the configuration of the HibernateTitleDao bean correct and present?
• The Hibernate mapping file configuration: is everything mapped correctly and are the correct lazy-loading settings in place?
• The logic of the HibernateTitleDao: does the configured instance of this class perform as anticipated?

Transaction management

One common issue in tests that access a real database is their affect on the state of the persistence store.Even when you're using a development data base, changes to the state may affect future tests. Also, many operations - such as inserting or modifying persistent data - cannot be performed (or verified) outside a transaction.

The Test Context frame work addresses this issue.By default, the frame work will create and roll back a transaction for each test. You simply write code that can assume the existence of a transaction. If you call transactionally proxied objects in your tests, they will behave correctly, according to their transactional semantics. In addition, if test methods delete the contents of selected tables while running within a transaction, the transaction will roll back by default, and the database will return to its state prior to execution of the test.Transactional support is provided to your test class via a Plat formT ransaction Manager bean defined in the test's application context.

If you want a transaction to commit - unusual, but occasionally useful when you want a particular test to populate or modify the database - the Test Context frame work can be instructed to cause the transaction to commit instead of roll back via the @Transaction Configuration and @Roll back annotations.

Support classes for integration testing

The Spring TestContext Framework provides several abstract support classes that simplify the writing of integration tests. These base test classes provide well-defined hooks into the testing framework as well as convenient instance variables and methods, which enable you to access:

• The Application Context, for performing explicit bean lookups or testing the state of the context as a whole.
• A Simple Jdbc Template, for querying to confirm state For example, you use an ORM tool to query before and after testing application code that creates an object and persists it, to verify that the data appears in the database.(Spring ensures that the query runs in the scope of the same transaction.) You need to tell your ORM tool to 'flush' its changes, by using,for example, the flush() method on Hibernate's Session interface.

In addition, you may want to create your own custom, application-wide super class with instance variables and methods specific to your project.

JDBC testing support

The org. spring frame work. test. jdbc package contains Simple Jdbc Test Utils, which is a Java-5-based collection of JDBC related utility functions intended to simplify standard database testing scenarios.Note that Abstract TransactionalJ Unit 38 Spring Context Tests,Abstract Transactional JUnit4 Spring Context Tests, and
Abstract Transactional Test NG Spring Context Tests provide convenience methods which
delegate to Simple Jdbc Test Utils internally.

Annotations

The Spring Framework provides the following set of Spring-specific annotations that you can use in your unit and integration tests in conjunction with the TestContext framework. Refer to the respective JavaDoc for further information, including default attribute values, attribute aliases, and so on.

@ContextConfiguration

Defines class-level metadata that is used to determine how to load and configure an ApplicationContext. Specifically, @ContextConfiguration defines the application context resource locations to load as well as the ContextLoader strategy to use for loading the context.

@DirtiesContext

Indicates that the underlying Spring Application Context has been dirtied (modified)as follows during the execution of a test and should be closed, regardless of whether the test passed:

• After the current test class, when declared on a class with class mode set to AFTER_CLASS, which is the default class mode.
• After each test method in the current test class, when declared on a class with class mode set to AFTER_EACH_TEST_METHOD.
• After the current test, when declared on a method.Use this annotation if a test has modified the context (for example, by replacing a bean definition). Sub sequent tests are supplied a new context.

Limitations of @DirtiesContext with JUnit 3.8

In a JUnit 3.8 environment @Dirties Context is only supported on methods and thus not at the class level.

You can use @Dirties Context as a class-level and method-level annotation within the same class.In such scenarios, the Application Context is marked as dirty after any such annotated method as well as after the entire class. If the ClassMode is set to AFTER_EACH_TEST_METHOD, the context is marked dirty after each test method in the class.

When an application context is marked dirty, it is removed from the testing framework's cache and closed; thus the underlying Spring container is rebuilt for any subsequent test that requires a context with the same set of resource locations.

@TestExecutionListeners

Defines class-level metadata for configuring which Test Execution Listeners should be registered with a Test Context Manager. Typically, @Test Execution Listeners are used in conjunction with @Context Configuration.

@Test Execution Listeners supports inherited listeners by default. See the JavaDoc for an example and further details.

@TransactionConfiguration

Defines class-level metadata for configuring transactional tests.Specifically, the bean name of the Platform Transaction Manager that is to be used to drive transactions can be explicitly configured if the bean name of the desired Platform Transaction Manager is not "transaction Manager".In addition, you can change the defaultRollback flag to false. Typically,

@Rollback

Indicates whether the transaction for the annotated test method should be rolled back after the test method has completed.If true, the transaction is rolled back; otherwise, the transaction is committed.Use @Rollback to override the default rollback flag configured at the class level.

@BeforeTransaction

Indicates that the annotated public void method should be executed before a transaction is started for test methods configured to run within a transaction through the @Transactional annotation.

@AfterTransaction

Indicates that the annotated public void method should be executed after a transaction has ended for test methods configured to run within a transaction through the @Transactional annotation.

@NotTransactional

The presence of this annotation indicates that the annotated test method must not execute in a transactional context.

@Not Transactional is deprecated

As of Spring 3.0, @Not Transactional is deprecated in favor of moving the non-transactional test method to a separate (non-transactional) test class or to a @Before Transaction or @After Transaction method.As an alternative to annotating an entire class with @Transactional, consider annotating individual methods with @Transactional; doing so allows a mix of transactional and non-transactional methods in the same test class without the need for using @Not Transactional.

The following annotations are only supported when used in conjunction with JUnit (that is., with the SpringJUnit4ClassRunner or the JUnit 3.8.2 and JUnit 4.5+ support classes.

@IfProfileValue

Indicates that the annotated test is enabled for a specific testing environment. If the configured Profile Value Source returns a matching value for the provided name, the test is enabled. This annotation can be applied to an entire class or to individual methods.Class-level usage overrides method-level usage.

Alternatively, you can configure @If Profile Value with a list of values (with OR semantics) to achieve TestNG-like support for test groups in a JUnit environment. Consider the following example:

@ProfileValueSourceConfiguration

Class-level annotation that specifies what type of Profile Value Source to use when retrieving profile values configured through the @IfProfileValue annotation.If @Profile Value Source Configuration is not declared for a test, System Profile Value Source is used by default.

@ExpectedException

Indicates that the annotated test method is expected to throw an exception during execution.The type of the expected exception is provided in the annotation, and if an instance of the exception is thrown during the test method execution then the test passes.Like wise if an instance of the exception is not thrown during the test method execution then the test fails.

Using Spring's @Expected Exception annotation in conjunction with JUnit 4's @Test(expected=...) configuration would lead to an unresolvable conflict. Developers must therefore choose one or the other when integrating with JUnit 4, in which case it is generally preferable to use the explicit JUnit 4 configuration.

@Timed

Indicates that the annotated test method must finish execution in a specified time period (in milliseconds). If the text execution time exceeds the specified time period, the test fails.

The time period includes execution of the test method itself, any repetitions of the test (see @Repeat), as well as any set up or tear down of the test fixture.

Spring's @Timed annotation has different semantics than JUnit 4's @Test(timeout=...) support.Specifically, due to the manner in which JUnit 4 handles test execution timeouts (that is, by executing the test method in a separate Thread), @Test(timeout=...) applies to each iteration in the case of repetitions and preem ptively fails the test if the test takes too long. Spring's @Timed, on the other hand, times the total test execution time (including all repetitions) and does not preemptively fail the test but rather waits for the test to complete before failing.

@Repeat

Indicates that the annotated test method must be executed repeatedly.The number of times that the test method is to be executed is specified in the annotation.

The scope of execution to be repeated includes execution of the test method itself as well as any set up or tear down of the test fixture.

The following non-test-specific annotations are supported with standard semantics for all configurations of the Spring TestContext Framework.

• @Autowired
• @Qualifier
• @Resource (javax.annotation) if JSR-250 is present
• @Inject (javax.inject) if JSR-330 is present
• @Named (javax.inject) if JSR-330 is present
• @Provider (javax.inject) if JSR-330 is present
• @PersistenceContext (javax.persistence) if JPA is present
• @PersistenceUnit (javax.persistence) if JPA is present
• @Required
• @Transactional

Spring TestContext Framework

The Spring TestContext Framework (located in the org. spring frame work. test. context package) provides generic, annotation-driven unit and integration testing support that is agnostic of the testing framework in use, whether JUnit 3.8.2, JUnit 4.5+, TestNG 5.10, and so on. The Test Context frame work also places a great deal of importance on convention over configuration with reasonable defaults that can be overridden through annotation-based configuration.

In addition to generic testing infra structure, the TestContext frame work provides explicit support for JUnit 3.8.2, JUnit 4.5+, and TestNG 5.10 in the form of abstract support classes. For JUnit 4.5+, the framework also provides a custom Runner that allows one to write test classes that are not required to extend a particular class hierarchy.

The following provides an overview of the internals of the Test Context frame work. If you are only interested in using the frame work and not necessarily interested in extending it with your own custom listeners, feel free to go directly to the configuration (context management, dependency injection, transaction management), support classes, and annotation support sections.

Key abstractions

The core of the frame work consists of the Test Context and Test Context Manager classes and the Test Execution Listener interface. A Test Context Manager is created on a per-test basis. The Test Context Manager in turn manages a Test Context that holds the context of the current test.

The Test Context Manager also updates the state of the Test Context as the test progresses and delegates to Test Execution Listeners, which instrument the actual test execution, by providing dependency injection, managing transactions, and so on.Consult the Java Doc and the Spring test suite for further information and examples of various configurations.

• TestContext: Encapsulates the context in which a test is executed, agnostic of the actual testing framework in use.
• Test Contex tManager: The main entry point into the Spring Test Context Framework, which manages a single Test Context and signals events to all registered Test Execution Listeners at well-defined test execution points: test instance preparation, prior to any before methods of a particular testing frame work, and after any after methods of a particular testing framework.
• Tes tExecution Listener: Defines a listener API for reacting to test execution events published by the Test Context Manager with which the listener is registered.<

Spring provides three Test Execution Listener implementations that are configured by default:Dependency Injection Tes tExecution Listener,Dirties Context Test Execution Listener, and Transactional Test Execution Listener. Respectively, they support dependency injection of the test instance, handling of the @DirtiesContext annotation, and transactional test execution with default rollback semantics.

The following explain how to configure the TestContext frame work through annotations and provide working examples of how to write unit and integration tests with the framework.

Context management and caching

Each Test Context provides context management and caching support for the test instance for which it is responsible.Test instances do not automatically receive access to the configuredn Application Context.However,if a test class implements the Application Context Aware interface, a reference to the Application Context is supplied to the test instance, if the Dependency Injection Test Execution Listener is configured, which is the default.

Abstract JUnit38 Spring Context Tests, Abstract JUnit4 Spring Context Tests, and Abstract Test NG Spring Context Tests already implement Application Context Aware and therefore provide this functionality out-of-the-box.

@Autowired ApplicationContext

As an alternative to implementing the Application Context Aware interface, you can inject the application context for your test class through the @Autowired annotation on either a field or setter method. For example:

in contrast to the now deprecated JUnit 3.8 legacy class hierarchy, test classes that use the Test Context framework do not need to override any protected instance methods to configure their application context. Rather, configuration is achieved merely by declaring the @Context Configuration annotation at the class level.If your test class does not explicitly declare application context resource locations, the configured Context Loader determines how and whether to load a context from a default set of locations. For example, Generic Xml Context Loader, which is the default ContextLoader, generates a default location based on the name of the test class. If your class is named com.example. My Test, Generic Xml Context Loader loads your application context from

If the default location does not suit your needs, you can configure explicitly the locations attribute of @Context Configuration with an array that contains the resource locations of XML configuration metadata (assuming an XML-capable ContextLoader has been configured) - typically in the classpath.

- used to configure the application.(See the following code example.) This location will be the same, or nearly the same, as the list of configuration locations specified in web.xml or other deployment configuration. Alternatively, you can implement and configure your own custom ContextLoader.

@Context Configuration supports an alias for the locations attribute through the standard value attribute.Thus, if you do not need to configure a custom Context Loader, you can omit the declaration of the locations attribute name and declare the resource locations by using the shorthand format demonstrated in the following example.@Context Configuration also supports a Boolean inheritLocations attribute that denotes whether resource locations from superclasses should be inherited.The default value is true, which means that an annotated class inherits the resource locations defined by an annotated superclass.Specifically, the resource locations for an annotated class are appended to the list of resource locations defined by an annotated superclass.Thus, subclasses have the option of extending the list of resource locations. In the following example, the ApplicationContext for ExtendedTest is loaded from "/base-context.xml" and"/extended-context.xml", in that order. Beans defined in "/extended-context.xml" may therefore override
those defined in "/base-context.xml".

if inheritLocations is set to false, the resource locations for the annotated class shadows and effectively replaces any resource locations defined by a superclass.

By default, once loaded, the configured Application Context is reused for each test. Thus the setup cost is incurred only once (per test fixture), and subsequent test execution is much faster. In the unlikely case that a test dirties (modifies) the application context, requiring reloading -- for example, by changing a bean definition or the state of an application object -- you can annotate your test method with @Dirties Context (assuming Dirties Context Test Execution istener has been configured, which is the default) to cause the test fixture to reload the configurations and rebuild the application context before executing the next test.

Dependency Injection of test fixtures

When you configure the Dependency Injection Test Execution Listener -- which is configured by default through the @Test Execution Listeners annotation-- the dependencies of your test instances are injected from beans in the application context you configured through @Context Configuration by setter injection, field injection, or both, depending on which annotations you choose and whether you place them on setter methods or fields. For consistency with the annotation support introduced in Spring 2.5, you can use Spring's @Autowired annotation or the @Resource annotation from JSR 250. The semantics for both are consistent throughout the Spring Framework. For example, if you prefer autowiring by type, annotate your setter methods or fields with @Autowired. If you prefer to have your dependencies injected by name, annotate your setter methods or fields with @Resource.

Because @Autowired performs autowiring by type, if you have multiple bean definitions of the same type, you cannot rely on this approach for those particular beans. In that case, you can use @Resource for injection by name. Alternatively, if your test class has access to its Application Context, you can perform an explicit lookup by using (for example) a call to applicationContext.getBean("titleDao"). A third option is to use @Autowired in conjunction with @Qualifier.

If you do not want dependency injection applied to your test instances, simply do not annotate fields or setter methods with @Autowired or @Resource. Alternatively, you can disable dependency injection altogether by explicitly configuring your class with @TestExecutionListeners and omitting Dependency Injection Test Execution Listener.class from the list of listeners.

Consider the scenario of a class, Hibernate Title Dao, as outlined in the Goals. (We will look at the application context configuration after all sample code listings.) A JUnit 4-based implementation of the test class itself uses @Autowired for field injection.

Alternatively, you can configure the class to use @Autowired for setter injection.

Here is an example of @Resource for field injection.

Here is an example of @Resource for setter injection.

Transaction management

In the Test Context frame work, transactions are managed by the Transactional Test Execution Listener, which is configured through the @Test Execution Listeners annotation by default, even if you do not explicitly declare @TestExecutionListeners on your test class.To enable support for transactions, however, you must provide a PlatformTransactionManager bean in the application context loaded by @ContextConfiguration semantics.In addition, you must declare @Transactional either at the class or method level.

If transactions are not enabled for the entire test class, you can annotate methods explicitly with @Transactional.To control whether a transaction should commit for a particular test method, you can use the @Rollback annotation to override the class-level default rollback setting.Abstract Transactional JUnit38 Spring Context Tests Abstract Transactional JUnit4 Spring Context Tests, and Abstract Transactional Test NG Spring Context Tests are preconfigured for transactional support at the class level.

Occasionally you need to execute certain code before or after a transactional test method but outside the transactional context, for example, to verify the initial database state prior to execution of your test or to verify expected transactional commit behavior after test execution (for example, if the test was configured not to roll back the transaction).Transactional Test Execution Listener supports the @Before Transaction and @After Transaction annotations exactly for such scenarios. Simply annotate any public void method in your test class with one of these annotations, and the TransactionalTestExecutionListener ensures that your before transaction method or aftertransaction method is executed at the appropriate time.

The following JUnit 4 based example displays a fictitious integration testing scenario high lighting several transaction-related annotations.

Avoid false positives when testing ORM code

When you test code involving an ORM framework such as JPA or Hibernate, flush the underlying session within test methods which update the state of the session. Failing to flush the ORM framework's underlying session can produce false positives: your test may pass, but the same code throws an exception in a live, production environment. In the following

Hibernate-based example test case, one method demonstrates a false positive and the other method correctly exposes the results of flushing the session.

TestContext support classes

JUnit 3.8 support classes

The org.spring frame work.test.context.junit38 package provides support classes for JUnit 3.8 based test cases.

• Abstract JUnit38 Spring Context Tests: Abstract Test Case that integrates the Spring Test Context Frame work with explicit Application Context testing support in a JUnit 3.8 environment.When you extend the Abstract JUnit38 Spring Context Tests class, you need access to the following protected instance variables:
• application Context: Perform explicit bean lookups or test the state of the context as a whole.
• Abstract Transactional JUnit38 Spring Context Tests: Abstract transactional extension of Abstract JUnit38 Spring Context Tests that also adds some.
• convenience functionality for JDBC access. Expects a javax.sql.Data Source bean and a Platform Transaction Manager bean to be defined in the Application Context.When you extend the Abstract Transactional JUnit38 Spring Context Tests class, you will have access to the following protected instance variables:
• application Context: Inherited from the Abstract JUnit38 Spring Context Tests superclass. Use this variable to perform explicit bean lookups or to test the state of the context as a whole.
• simpleJdbcTemplate: Useful for querying to confirm state. For example, use an ORM tool to query before and after testing application code that creates an object and persists it, to verify that the data appears in the database. (Spring ensures that the query runs in the scope of the same transaction.) You need to tell your ORM tool to 'flush' its changes for this to work correctly by, for example, using the flush() method on Hibernate's Session interface.

JUnit 4.5+ support classes

The org.springframework.test.context.junit4 package provides support classes for JUnit 4.5+ based test cases.

• Abstract JUnit4 Spring Context Tests: Abstract base test class that integrates the Spring Test Context Framework with explicit ApplicationC ontext testing support in a JUnit 4.5+ environment.When you extend Abstract JUnit4 Spring Context Tests, you can access the following protected instance variable:
• applicationContext: Perform explicit bean lookups or test the state of the context as a whole.
• Abstract Transactional JUnit4 Spring Context Tests: Abstract transactional extension of Abstract JUnit4 Spring Context Tests that also adds some convenience functionality for JDBC access. Expects a javax. sql. Data Source bean and a Platform Transaction Manager bean to be defined in the Application Context. When you extend Abstract Transactional JUnit4 Spring Context Tests you can access the following protected instance variables:
• application Context: Inherited from the Abstract JUnit4 Spring Context Tests superclass. Perform explicit bean lookups or test the state of the context as a whole.
• simpleJdbcTemplate: Useful for querying to confirm state. For example, use an ORM tool to query before and after testing application code that creates an object and persists it, to verify that the data appears in the database. (Spring ensures that the query runs in the scope of the same transaction.) You need to tell your ORM tool to 'flush' its changes for this to work correctly by, for example, using the flush() method on Hibernate's Session interface.

Custom JUnit 4.5+ Runner

The Spring Test Context Frame work offers full integration with JUnit 4.5+ through a custom runner (tested on JUnit 4.5, 4.6, and 4.7). By annotating test classes with @Run With (Spring JUnit4 Class Runner. class), developers can implement standard JUnit 4.5+ unit and integration tests and simultaneously reap the benefits of the Test Context frame work such as support for loading application contexts, dependency injection of test instances, transactional test method execution, and so on. The following code listing displays the minimal requirements for configuring a test class to run with the custom Spring Runner.@Test Execution Listeners is configured with an empty list in order to disable the default listeners, which otherwise would require an Application Context to be configured through @Context Configuration.

TestNG support classes

The org.springframework.test.context.testng package provides support classes for TestNG based test cases.

• Abstract Test NG Spring Context Tests: Abstract base test class that integrates the Spring Test Context Frame work with explicit Application Context testing support in a Test NG environment.

When you extend AbstractTestNGSpringContextTests you can access the following protected instance variable:

• application Context: Perform explicit bean lookups or test the state of the context as a whole.
• Abstract Transactional Test NG Spring Context Tests: Abstract transactional extension of Abstract Test NG Spring Context Tests that adds some convenience functionality for JDBC access. Expects a javax.sql. Data Source bean and a Platform Transaction Manager bean to be defined in the Application Context. When you extend Abstract Transactional Test NG Spring Context Tests, you can access the following protected instance variables:
• application Context: Inherited from the Abstract Test NG Spring Context Tests superclass. Perform explicit bean lookups or test the state of the context as a whole.
• simple Jdbc Template: Useful for querying to confirm state. For example, use an ORM tool to query before and after testing application code that creates an object and persists it, to verify that the data appears in the database.(Spring ensures that the query runs in the scope of the same transaction.) You need to tell your ORM tool to 'flush' its changes for this to work correctly by, for example, using the flush() method on Hibernate's Session interface.

PetClinic example

The Pet Clinic application, available from the samples repository, illustrates several features of the Spring Test Context Frame work in a JUnit 4.5+ environment. Most test functionality is included in the Abstract Clinic Tests, for which a partial listing is shown below:

Notes:

• This test case extends the Abstract Transactional JUnit4 pring Context Tests class, from which it inherits configuration for Dependency Injection (through the Dependency Injection TestE xecution Listener) and transactional behavior (through the Transactional Test Execution Listener).
• The clinic instance variable - the application object being tested - is set by Dependency Injection through @Auto wired semantics.
• The test Get Vets() method illustrates how you can use the inherited count Rows In Table() method to easily verify the number of rows in a given table, thus testing correct behavior of the application code being tested. This allows for stronger tests and lessens dependency on the exact test data. For example, you can add additional rows in the database with out breaking tests.
• Like many integration tests that use a database, most of the tests in Abstract Clinic Tests depend on a minimum amount of data already in the database before the test cases run. You might, however, choose to populate the database in your test cases also - again, within the same transaction.

The Pet Clinic application supports three data access technologies: JDBC, Hibernate, and JPA. By declaring @Context Configuration without any specific resource locations, the Abstract Clinic Tests class will have its application context loaded from the default location, Abstract Clinic Tests-context.xml, which declares a common Data Source. Sub classes specify additional context locations that must declare a Platform Transaction Manager and a concrete implementation of Clinic.

For example, the Hibernate implementation of the PetClinic tests contains the following implementation.For this example, Hibernate Clinic Tests does not contain a single line of code: we only need to declare @Context Configuration, and the tests are inherited from Abstract Clinic Tests.

Because @Context Configuration is declared without any specific resource locations, the SpringTest Context Frame work loads an application context from all the beans defined in Abstract Clinic Tests-context.xml (that is, the inherited locations) and Hibernate Clinic Tests-context.xml, with Hibernate Clinic Tests-context.

xml possibly overriding beans defined in Abstract Clinic Tests-context.xml.

As far as possible, you should have exactly the same Spring configuration files in your integration tests as in the deployed environment. One likely point of difference concerns database connection pooling and transaction infrastructure If you are deploying to a full-blown application server, you will probably use its connection pool (available through JNDI) and JTA implementation.

Thus in production you will use a Jndi Object Factory Bean / <jee:jndi-lookup> for the DataSource and JtaTransaction Manager. JNDI and JTA will not be available in out-of-container integration tests, so you should use a combination like the Commons DBCP Basic Data Source and Data Source Transaction Manager or Hibernate Transaction Manager for them. You can factor out this variant behavior into a single XML file, having the choice between application server and a 'local' configuration separated from all other configuration, which will not vary between the test and production environments. In addition, it is advisable to use properties files for connection settings: see the PetClinic application for an example.