Another in a series of posts that in no small part will serve as
summaries/reminders to myself on various readings on the topic of
automated code testing. Perhaps others will find them useful though.
I can't take credit for any terribly creative conjectures in my
conclusions/summaries. They almost exclusively come from the writers
in the referenced material. I would strongly encourage reading the
original source materials for far more details and a better
understanding of the topics.
Testing Theories Part 1 - Classical vs Mock Testing
Testing Theories Part 2 - Unit Testing with Inversion of Control Pro's/Con's
Testing Theories Part 3 - IoC Containers (Castle Windsor, Spring.NET), AutoMocking Containers
Testing Theories Part 4 - TypeMock Isolator - The Dark Horse of Unit Testing? IoC can certainly be done manually without the help of a container, but there are advantages to using one.
- Can configure external dependencies in config for class so each time it's used the dependencies are automatically wired up. No setting properties or passing lots of interface reference parameters each time.
- Can you separate config for unit test, pre-production environment staging, and production so no code changes for where your dependencies/resources come from. Integration tests on a test environment can use a local copy of the DB or completely mock the data layer altogether. Code based config right in the unit tests is also a possibility.
- The container saves you the trouble of writing specialized factory classes to configure your objects for various roles.
- Dependency lists serve as a form of implicit documentation for your classes and how they are connected.
AutoMockingContainers automatically create dynamic mocks for all dependency references needed for the class in test and the specific portion of functionality being tested can then be setup with expectations. It cleans out the setup part of your tests a bit and cuts down on repetition.
JP Boodhoo and David provide similar BDD base class implementations using Windsor AutoMocking container to further clean up redundant test code.
---
Resources
Castle Windsor
http://dotnetslackers.com/articles/designpatterns/InversionOfControlAndDependencyInjectionWithCastleWindsorContainerPart1.aspx
http://dotnetslackers.com/articles/designpatterns/InversionOfControlAndDependencyInjectionWithCastleWindsorContainerPart2.aspx
http://dotnetslackers.com/articles/designpatterns/InversionOfControlAndDependencyInjectionWithCastleWindsorContainerPart3.aspx
http://dotnetslackers.com/articles/designpatterns/InversionOfControlAndDependencyInjectionWithCastleWindsorContainerPart4.aspx
http://msdn2.microsoft.com/en-us/library/aa973811.aspx
Windsor AutoMockingContainer
http://blog.eleutian.com/2007/02/23/TestsAutoMockingIoCContainer.aspx
http://blog.eleutian.com/2007/08/05/UsingTheAutoMockingContainer.aspx
http://www.ayende.com/Blog/archive/2007/06/08/The-Auto-Mocking-Container.aspx
Spring.NET
http://www.developer.com/net/csharp/article.php/10918_3722931_1
http://forum.springframework.net/showthread.php?t=4201 - AutoMock Spring
http://www.ibm.com/developerworks/library/j-mocktest.html - Java example but still useful for reference
Helper Base Classes for TDD/BDD
http://codebetter.com/blogs/david_laribee/archive/2007/12/17/approaching-bdd.aspx
http://codebetter.com/blogs/jean-paul_boodhoo/archive/2007/12/19/bdd-specification-base-class.aspx