Showing posts with label TypeMock. Show all posts
Showing posts with label TypeMock. Show all posts

Thursday, January 28, 2010

UnitTesting made easy with the power of TypeMock

I want to test the persistence layer of my code. One of the recently added requirements for the persistence layer is that it accepts a domain class that wraps around the user name to ensure consistent handling throughout the application of a username. This is because currently the decision is to strip the Windows Domain name off of a userName before using it or storing it. Should the decision be reversed, there's a central configuration alteration to make, without having to recompile the application. How nice are changes that require a simple text file to be changed?

So the call would be:

var result=repository.GetAssociate(new UserName(DependencyContainer.GetAssociate()));
Which you can't call from the persistence layer because
  • The Dependency container is defined in an assembly not referenced by the persistence layer 
  • The UserName constructor is internal to the domain assembly
So to make the method repository.GetAssociate testable, we would have to alter the OOP design of the code to make it testable in most frameworks( because there is no public constructor for UserName).

You could of course messy up your code by using dependency injection on everything that needs testing. This concern does partly fall down if you centralize the coupling between your domain and external dependencies, but remains when you try to test individual methods inside a class, or anything internal, private, or that accesses static methods(most testing frameworks can not handle mocking out static methods, constructors, or factories, as I understand it TypeMock can)

You could make your code messier and more prone to issues in dependent code by changing username to a public interface and changing the persistence layer to accept that interface, but then automatic business logic enforcement goes out the window. If an object outside of the domain assembly can not create a copy of a domain object it has no reason to create, then it's tougher to accidentally not pass things through the proper domain classes/methods.

So how do I test this method?