I use AutoMockingContainer extensively in my test projects, and I ‘ve build over time an automocking container that satisfy all of my needs. Thanks to Castle Windsor, using complex logic with the AutomockingContainer is a breeze. Suppose you have this ViewModel
Figure 1: ViewModel under test
The only aspect I’m interested in is the SelectedLinkResult public property, that have a lot of logic in the set part, this is needed to react on user selection change in the UI. Now when I use AutoMockingContainer to automock this view model I have a big problem, I need to setup a lot of expectations to make the setter logic to work, this because when I try to resolve with automock, my AutoMockingContainer try to resolve each dependency, even properties. To avoid this I need to be able to tell my container
- Avoid to resolve any property
- Avoid to resolve dependencies with specific name
The second one is needed if I want some properties to be resolved and some other to be excluded, so I needs to extend my container with a couple of properties.
I’ve added a List of property name to ignore, a property that specify if I want properties to be resolved, and finally a simple function that tells if a specific property needs to be resolved. Thanks to Castle, I can use these properties from the subresolver used by the container.
First of all I check if the dependencyType is Service and calls the CAnSatisfyDependencyKey of the subresolver, then if the the dependency is optional (a property) and the ResolveProperties is false, I skip resolution. Now I can write a unit test header like this one:
This to avoid completely Property resolving during the test, the following one is used if I want only the SelectedLinkResult property not to be resolved with a Mock.
This makes my tests really simple and simple to write.