From 2302c5ac9d077c4789746e3e49ea100aac6b2506 Mon Sep 17 00:00:00 2001 From: markpollack Date: Tue, 28 Jul 2009 06:22:26 +0000 Subject: [PATCH] SPRNET-1196 - MSTest support --- doc/reference/src/testing.xml | 203 ++++++++++++++++------------------ 1 file changed, 98 insertions(+), 105 deletions(-) diff --git a/doc/reference/src/testing.xml b/doc/reference/src/testing.xml index af78d1d0..956f5867 100644 --- a/doc/reference/src/testing.xml +++ b/doc/reference/src/testing.xml @@ -16,7 +16,12 @@ * limitations under the License. */ --> - + Testing
@@ -74,46 +79,22 @@ - The Spring Framework provides first class support for integration - testing in the form of the classes that are packaged in the Spring.Testing.NUnit.dll library. - Please note that these test classes are NUnit-specific. Support - for mbUnit and VSTS are under consideration for future - versions. + The Spring Framework provides support for integration testing when + using NUnit and Microsoft's Testing framework 'MSTest'. The NUnit classses + are located in the assembly Spring.Testing.NUnit.dll and the MSTest is + located in Spring.Testing.Microsoft.dll. - The Spring.Testing.NUnit.dll library is compiled against NUnit - 2.4.1. At the time of this writing the latest version of NUnit is 2.4.6. - Note that add-in have their own versions of NUnit they use. For example, - ReSharper 3.0 uses 2.2.8. If you are using the GUI-runner that comes - with NUnit then you should add the following to your .config file, (in - the form of MyAssembly.dll.config) - - <runtime> - - <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> - - <dependentAssembly> - <assemblyIdentity name="nunit.framework" - publicKeyToken="96d09a1eb7f44a77" - culture="neutral"/> - <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535 - newVersion="2.4.6.0"/> - - </dependentAssembly> - - </assemblyBinding> - -</runtime> + The Spring.Testing.NUnit.dll library is + compiled against NUnit 2.5.1. Note that test runners integrated inside + VS.NET may or may not support this version. At the time of this writing + Reshaper 4.5.0 did not properly support NUnit 2.5.1. To use Resharper + with NUnit 2.5.1 you need to download 4.5.1 RC2 or later. - The Spring.Testing.NUnit namespace provides - valuable NUnit TestCase superclasses for - integration testing using a Spring container. Note that as of NUnit 2.4 - these can be rewritten in terms of custom attributes via NUnit's new - extensibility mechanism. This will be an additional option in an upcoming - release of Spring.NET and is already present in the Java version of the - Spring framework. + These namespaces provides NUnit and MSTest superclasses for + integration testing using a Spring container. These superclasses provide the following functionality: @@ -144,22 +125,23 @@
Context management and caching - The Spring.Testing.NUnit - package provides support for consistent loading of Spring contexts, and - caching of loaded contexts. Support for the caching of loaded contexts - is important, because if you are working on a large project, startup - time may become an issue - not because of the overhead of Spring itself, - but because the objects instantiated by the Spring container will - themselves take time to instantiate. For example, a project with 50-100 - NHibernate mapping files might take 10-20 seconds to load the mapping - files, and incurring that cost before running every single test case in - every single test fixture will lead to slower overall test runs that - could reduce productivity. + The Spring.Testing.NUnit and + Spring.Testing.Microsoft namespace provides support + for consistent loading of Spring contexts, and caching of loaded + contexts. Similarly Spring.TestingSupport for the caching of loaded + contexts is important, because if you are working on a large project, + startup time may become an issue - not because of the overhead of Spring + itself, but because the objects instantiated by the Spring container + will themselves take time to instantiate. For example, a project with + 50-100 NHibernate mapping files might take 10-20 seconds to load the + mapping files, and incurring that cost before running every single test + case in every single test fixture will lead to slower overall test runs + that could reduce productivity. To address this issue, the - AbstractDependencyInjectionSpringContextTests has - an protected property that subclasses must implement - to provide the location of context definition files: + AbstractDependencyInjectionSpringContextTests has an + protected property that subclasses must implement to + provide the location of context definition files: protected abstract string[] ConfigLocations { get; } @@ -186,26 +168,25 @@ Dependency Injection of test fixtures When - AbstractDependencyInjectionSpringContextTests - (and subclasses) load your application context, they can optionally - configure instances of your test classes by Setter Injection. All you - need to do is to define instance variables and the corresponding - setters. - AbstractDependencyInjectionSpringContextTests - will automatically locate the corresponding object in the set of + AbstractDependencyInjectionSpringContextTests (and + subclasses) load your application context, they can optionally configure + instances of your test classes by Setter Injection. All you need to do + is to define instance variables and the corresponding setters. + AbstractDependencyInjectionSpringContextTests will + automatically locate the corresponding object in the set of configuration files specified in the ConfigLocations property. Consider the scenario where we have a class, - HibernateTitleDao, that performs data access - logic for say, the Title domain object. We want - to write integration tests that test all of the following areas: + HibernateTitleDao, 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 - object correct and present? + the configuration of the HibernateTitleDao object + correct and present? @@ -214,16 +195,17 @@ - The logic of the HibernateTitleDao; - does the configured instance of this class perform as - anticipated? + The logic of the HibernateTitleDao; does + the configured instance of this class perform as anticipated? - Let's look at the test class itself (we will look at the + Let's look at the NUnit test class itself (we will look at the configuration immediately afterwards). - [TestFixture] + /// Using NUnit + +[TestFixture] public class HibernateTitleDaoTests : AbstractDependencyInjectionSpringContextTests { // this instance will be (automatically) dependency injected @@ -266,22 +248,51 @@ public class HibernateTitleDaoTests : AbstractDependencyInjectionSpringContextTe </objects> The - AbstractDependencyInjectionSpringContextTests - classes uses autowire - by type. Thus if you have multiple object definitions - of the same type, you cannot rely on this approach for those particular + AbstractDependencyInjectionSpringContextTests classes + uses autowire by + type. Thus if you have multiple object definitions of + the same type, you cannot rely on this approach for those particular object. In that case, you can use the inherited applicationContext instance variable, and explicit lookup using (for example) an explicit call to applicationContext.GetObject("titleDao"). + Using AbstractDependencyInjectionSpringContextTests with MSTest is + very similar. + + /// Using Microsoft's Testing Framework + +[TestClass] +public class HibernateTitleDaoTests : AbstractDependencyInjectionSpringContextTests { + + // this instance will be (automatically) dependency injected + private HibernateTitleDao titleDao; + + // a setter method to enable DI of the 'titleDao' instance variable + public HibernateTitleDao HibernateTitleDao { + set { titleDao = value; } + } + + [Test] + public void LoadTitle() { + Title title = this.titleDao.LoadTitle(10); + Assert.IsNotNull(title); + } + + // specifies the Spring configuration to load for this test fixture + protected override string[] ConfigLocations { + return new String[] { "assembly://MyAssembly/MyNamespace/daos.xml" }; + } + +} + If you don't want dependency injection applied to your test cases, simply don't declare any set properties. Alternatively, you can extend the AbstractSpringContextTests - the root of the - class hierarchy in the Spring.Testing.NUnit - namespace. It merely contains convenience methods to load Spring - contexts, and performs no Dependency Injection of the test - fixture. + class hierarchy in the Spring.Testing.NUnit and + Spring.Testing.Microsoft namespaces. It merely + contains convenience methods to load Spring contexts, and performs no + Dependency Injection of the test fixture.
Field level injection @@ -304,7 +315,7 @@ public class HibernateTitleDaoTests : AbstractDependencyInjectionSpringContextTe // this instance will be (automatically) dependency injected protected HibernateTitleDao titleDao; - [Test] + [TestMethod] public void LoadTitle() { Title title = this.titleDao.LoadTitle(10); Assert.IsNotNull(title); @@ -341,10 +352,10 @@ public class HibernateTitleDaoTests : AbstractDependencyInjectionSpringContextTe transactionally proxied objects in your tests, they will behave correctly, according to their transactional semantics. - AbstractTransactionalSpringContextTests - depends on a IPlatformTransactionManager object - being defined in the application context. The name doesn't matter, due - to the use of autowire by type. + AbstractTransactionalSpringContextTests depends + on a IPlatformTransactionManager object being defined + in the application context. The name doesn't matter, due to the use of + autowire by type. Typically you will extend the subclass, AbstractTransactionalDbProviderSpringContextTests. @@ -358,8 +369,8 @@ public class HibernateTitleDaoTests : AbstractDependencyInjectionSpringContextTe If you want a transaction to commit - unusual, but occasionally useful when you want a particular test to populate the database - you can call the SetComplete() method inherited - from AbstractTransactionalSpringContextTests. - This will cause the transaction to commit instead of roll back. + from AbstractTransactionalSpringContextTests. This + will cause the transaction to commit instead of roll back. There is also convenient ability to end a transaction before the test case ends, through calling the @@ -385,9 +396,8 @@ public class HibernateTitleDaoTests : AbstractDependencyInjectionSpringContextTe applicationContext (a - IConfigurableApplicationContext): - inherited from the - AbstractDependencyInjectionSpringContextTests + IConfigurableApplicationContext): inherited from + the AbstractDependencyInjectionSpringContextTests superclass. Use this to perform explicit object lookup, or test the state of the context as a whole. @@ -408,24 +418,7 @@ public class HibernateTitleDaoTests : AbstractDependencyInjectionSpringContextTe Often you will provide an application-wide superclass for integration tests that provides further useful instance variables used - in many tests + in many tests.
- -
- -
- Further Resources - - This section contains links to further resources about testing in - general. - - - - The NUnit - homepage. The Spring Framework's unit test suite is written - using NUnit as the testing framework. - - -
- \ No newline at end of file +