Spring.Testing.Microsoft Convenient superclass for tests depending on a Spring context. The test instance itself is populated by Dependency Injection.

Really for integration testing, not unit testing. You should not normally use the Spring container for unit tests: simply populate your objects in plain NUnit tests!

This supports two modes of populating the test:

  • Via Property Dependency Injection. Simply express dependencies on objects in the test fixture, and they will be satisfied by autowiring by type.
  • Via Field Injection. Declare protected variables of the required type which match named beans in the context. This is autowire by name, rather than type. This approach is based on an approach originated by Ara Abrahmian. Property Dependency Injection is the default: set the "populateProtectedVariables" property to true in the constructor to switch on Field Injection.

This class will normally cache contexts based on a context key: normally the config locations String array describing the Spring resource descriptors making up the context. Unless the SetDirty() method is called by a test, the context will not be reloaded, even across different subclasses of this test. This is particularly beneficial if your context is slow to construct, for example if you are using Hibernate and the time taken to load the mappings is an issue.

If you don't want this behavior, you can override the ContextKey property, most likely to return the test class. In conjunction with this you would probably override the GetContext method, which by default loads the locations specified by the ConfigLocations property.

WARNING: When doing integration tests from within VS.NET, only use assembly resource URLs. Else, you may see misleading failures when changing context locations.

 Rod Johnson Rob Harrop Rick Evans Aleksandar Seovic (.NET) Superclass for NUnit test cases using a Spring context.

Maintains a cache of contexts by key. This has significant performance benefit if initializing the context would take time. While initializing a Spring context itself is very quick, some objects in a context, such as a LocalSessionFactoryObject for working with NHibernate, may take time to initialize. Hence it often makes sense to do that initializing once.

Normally you won't extend this class directly but rather extend one of its subclasses.

 Rod Johnson Aleksandar Seovic (.NET) Map of context keys returned by subclasses of this class, to Spring contexts. Static ctor to avoid "beforeFieldInit" problem. Disposes any cached context instance and removes it from cache. Indicates, whether context instances should be automatically registered with the global . Logger available to subclasses. Default constructor for AbstractSpringContextTests. Set custom locations dirty. This will cause them to be reloaded from the cache before the next test case is executed. Call this method only if you change the state of a singleton object, potentially affecting future tests. Locations Returns true if context for the specified is cached. Context key to check. true if context for the specified is cached, false otherwise. Converts context key to string. Subclasses can override this to return a string representation of their contextKey for use in logging. Context key to convert. String representation of the specified . Null if contextKey is null. Caches application context. Key to use. Context to cache. Returns cached context if present, or loads it if not. Context key. Spring application context associated with the specified key. Loads application context from the specified resource locations. Resources to load object definitions from. Loads application context based on user-defined key. Unless overriden by the user, this method will alway throw a . User-defined key. Controls, whether application context instances will be registered/unregistered with the global . Defaults to true. Application context this test will run against. Holds names of the fields that should be used for field injection. Default constructor for AbstractDependencyInjectionSpringContextTests. Called to say that the "applicationContext" instance variable is dirty and should be reloaded. We need to do this if a test has modified the context (for example, by replacing an object definition). Test setup method. Inject dependencies into 'this' instance (that is, this test instance).

The default implementation populates protected variables if the property is set, else uses autowiring if autowiring is switched on (which it is by default).

You can certainly override this method if you want to totally control how dependencies are injected into 'this' instance.

 Loads application context from the specified resource locations. Resources to load object definitions from. Retrieves the names of the fields that should be used for field injection. Injects protected fields using Field Injection. Called right before a field is being injected Subclasses can override this method in order to add custom test setup logic. Test teardown method. Subclasses can override this method in order to add custom test teardown logic. Gets or sets a flag specifying whether to populate protected variables of this test case. A flag specifying whether to populate protected variables of this test case. Default is false. Gets or sets the autowire mode for test properties set by Dependency Injection. The autowire mode for test properties set by Dependency Injection. The default is . Gets or sets a flag specifying whether or not dependency checking should be performed for test properties set by Dependency Injection.

A flag specifying whether or not dependency checking should be performed for test properties set by Dependency Injection.

The default is true, meaning that tests cannot be run unless all properties are populated.

 Gets the current number of context load attempts. Gets a key for this context. Usually based on config locations, but a subclass overriding buildContext() might want to return its class. Subclasses must implement this property to return the locations of their config files. A plain path will be treated as a file system location. An array of config locations Subclass of AbstractTransactionalSpringContextTests that adds some convenience functionality for ADO.NET access. Expects a IDbProvider object to be defined in the Spring application context. This class exposes a AdoTemplate and provides an easy way to delete from the database in a new transaction. Rod Johnson Juergen Hoeller Mark Pollack (.NET) Convenient superclass for tests that should occur in a transaction, but normally will roll the transaction back on the completion of each test.

This is useful in a range of circumstances, allowing the following benefits:

  • Ability to delete or insert any data in the database, without affecting other tests
  • Providing a transactional context for any code requiring a transaction
  • Ability to write anything to the database without any need to clean up.

This class is typically very fast, compared to traditional setup/teardown scripts.

If data should be left in the database, call the SetComplete() method in each test. The "DefaultRollback" property, which defaults to "true", determines whether transactions will complete by default.

It is even possible to end the transaction early; for example, to verify lazy loading behavior of an O/R mapping tool. (This is a valuable away to avoid unexpected errors when testing a web UI, for example.) Simply call the endTransaction() method. Execution will then occur without a transactional context.

The StartNewTransaction() method may be called after a call to EndTransaction() if you wish to create a new transaction, quite independent of the old transaction. The new transaction's default fate will be to roll back, unless setComplete() is called again during the scope of the new transaction. Any number of transactions may be created and ended in this way. The final transaction will automatically be rolled back when the test case is torn down.

Transactional behavior requires a single object in the context implementing the IPlatformTransactionManager interface. This will be set by the superclass's Dependency Injection mechanism. If using the superclass's Field Injection mechanism, the implementation should be named "transactionManager". This mechanism allows the use of this superclass even when there's more than one transaction manager in the context.

This superclass can also be used without transaction management, if no IPlatformTransactionManager object is found in the context provided. Be careful about using this mode, as it allows the potential to permanently modify data. This mode is available only if dependency checking is turned off in the AbstractDependencyInjectionSpringContextTests superclass. The non-transactional capability is provided to enable use of the same subclass in different environments.

 Rod Johnson Juergen Hoeller Rick Evans Mark Pollack (.NET) The transaction manager to use Should we roll back by default? Should we commit the current transaction? Number of transactions started Default transaction definition is used. Subclasses can change this to cause different behaviour. TransactionStatus for this test. Typical subclasses won't need to use it. Initializes a new instance of the class. Prevents the transaction. Creates a transaction Callback method called before transaction is setup. Callback method called after transaction is setup. rollback the transaction. Callback before rolling back the transaction. Callback after rolling back the transaction. Set the complete flag.. Ends the transaction. Starts the new transaction. Sets the transaction manager to use. Sets the default rollback flag. Set the to be used Defaults to Holds the that this base class manages Did this test delete any tables? If so, we forbid transaction completion, and only allow rollback. Initializes a new instance of the class. Convenient method to delete all rows from these tables. Calling this method will make avoidance of rollback by calling SetComplete() impossible. Overridden to prevent the transaction committing if a number of tables have been cleared, as a defensive measure against accidental permanent wiping of a database. Counts the rows in given table. Name of the table to count rows in. The number of rows in the table Sets the DbProvider, via Dependency Injection. The IDbProvider. Gets or sets the AdoTemplate that this base class manages. The ADO template.