TypeMock - Allows Me Not To Decouple Too Far

I just had a situation today that emphasized to me why TypeMock can be so useful.

Design

IDomainChangeTrackingService interface in a domain assembly implemented by an infrastructure service class (DomainChangeTrackingService) in another assembly. We use DI with a ServiceLocator to get the implementation of the service into the domain.
Initially the DomainChangeTrackingService just persists the DomainChangeMessages passed to it, so all it does is call out to the DomainChangeMessageRepository:

public class DomainChangeTrackingService : IDomainChangeTrackingService
{
   public void ProcessMessage(DomainChangeMessage message)
   {
       new DomainChangeMessageRepository().Save(message);
   }
}

Testing

I've already written integration tests for the DomainChangeMessageRepository so when testing the DomainChangeTrackingService a single interaction test that just checks it calls the DomainChangeMessageRepository would be enough.

The problem was that DomainChangeTrackingService creates and uses the DomainChangeMessageRepository.

Without TypeMock I'd probably have handled this with more decoupling. I'd probably have made the repository implements an interface and the implementation of that interface is injected into DomainChangeTrackingService (or it could get it from the service locator).

This could be useful in the future but I'm certainly not wanting to worry about it right now and certainly isn't decoupling I'd be looking for. For me this is one the situations where TypeMock is great, I can interaction test DomainChangeTrackingService without having to change my design.

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone

Roy Osherove - The Case For TypeMock

Roy Osherove has another post on the case for TypeMock.

For me the big one is that design for testability has its limits. Breaking encapsulation, interfaces over all your classes, injecting everything, virtual members everywhere. Those things can be good and they can also lead to klunky designs particular in domain/business code).

That doesn't mean that design for testability isn't good. However when I want to mock something without changing its design, because I'm quite happy with its current design, I turn to TypeMock.

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone

TypeMock and Design

Roy Osherove has an interesting post on TypeMock/DI and design, it's a response to this post which is also interesting. In turn Jeremy Miller has put up his own response to Roy Osherove.

It's a well discussed topic and I've already put forward my views on it so I won't repeat them here but it is interesting that views on TypeMock are becoming more reasonable as time passes.

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone

TypeMock v IoC (Round 1)

Lots of discussion has kicked off about TypeMock v IoC:

1. Pro TypeMock - I don't agree with some of this, though I can see the authors point. For me the arguments for depdendency inversion are all in Robert Martins excellent book.
2. Good Summary - Agreeing with both camps seems sensible :)
3. Pro DI - Good summary of where DI is useful.
4. Pro DI 2 - Another discussion on where DI can help.
5. DI In Context - Really good post with the start of a (hopefully) long and important discussion of how DI relates to different layers.
6. DI and other patterns - Interface programming, SRP and the rest.
7. More Pro DI - Another good article on it.

Ultimately I think both have their place and some of the comments are also insightful, in particular I liked Mats Helanders comments to Ayendes post:

When writing an application, you may well be able to analyze in advance to see where you need pluggability points and provide interfaces there. Adding interfaces where you don't anticipate any use for them would of course be a violation of YAGNI.

I really like interface based programming and buy into it. In particular Robert Martins book (one of my favorite programming books) really goes into depth about how to decouple systems. However there is a cost and if you apply the principles too widely I think you get a mess, in particular when you are talking about your core domain/business classes.

I also don't fully agree with the vociferous arguments against TypeMock, I think it can be quite useful where you've looked at your design and decided your happy with it but you also want to do a bit of mocking.

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone

Testing the Domain

We've been having a lot of discussion in our company about how to test the domain and we've learned a lot from the discussion that I thought was worth sharing.

State Testing
My general view is that testing your domain classes against their public interfaces using state testing is a valid choice. The way we have chosen do this is:

1. Only use real domain objects in the tests, no mocking.
2. In general test against the public interfaces of public domain classes.

Eric Evans contributed to a DDD forum thread about this topic and I have to say I agree completely.

Where it does get interesting is where we are using state (as in state pattern) based validation in our domain objects. Nilsson summarizes the problem:

"In reality, adding rules also creates problems with testing. You nee to setup instances to correct states. You can write test helpers (such as private methods) for dealing with that, but it's still a hindrance."

The solution we've gone for up till now is an ObjectMother based approach, so for instance we have a CustomerObjectMother than can produce Customers in all sorts of different states. So if you are testing an Order and you need a Customer in the Active state then you can call into the CustomerObjectMother to get it. The object mother classes have all sorts of different creation/attachment methods.

This approach is definitely not without its flaws, including:

1. The domain should be enforcing/encapsulating quite a lot so testing it can be more complex than testing the individual (encapsulated) classes within the domain.
2. If we modify the Customer code and break it then its possible lots tests will break because they use the Customer class in the SUT setup phase (e.g we need a Customer even though we're testing the Order).

The main advantages of the approach are:

1. Tests at the public interface level mean that we can refactor within the domain safely because they act as a good safety net.
2. They point out places where the design is a bit overly complex (e.g. if we have lots of Customer states then the ObjectMother has to handle them all).

Decision Time

We've decided to have two levels of tests within the domain, we haven't got good names but essentially they will be:

1. Domain Tests - Testing at the public interface with real objects, mainly state testing.
2. Interation Tests - Detailed white box tests going right into the internal classes within the domain, mocking and doing interaction testing as appropriate.

This seems a good compromise, you are testing the public interface so all us TDDers can refactor happily below the public interface level but we've got detailed tests for the smaller classes.

The next question is how many of each test to have, hopefully good coverage by both and a lot of reuse but we'll have to see how that goes. Good.

Interaction Tests

However we have to decide how to mock the domain classes. I'm not at all in favor of covering my domain classes in interfaces, some people do it but there are valid reasons not to not least that the interfaces we put in for mocking hide the real meaningful abstractions within the domain.

Plus in this case we'll often be mocking classes internal to the domain (as in accessibility of internal in .NET). We can do this because we use InternalsVisibleToAttribute to give our unit tests access to the internals of the domain but do we really want to design our internal classes so that they are more easily mockable, then use depdency injection.

An example might help here, lets say our Customer class uses a custom collection called CustomerAddressCollection. This collection has complex logic to track the temporal nature of addresses and the fact that addresses have different purposes (home/work). Users of the Customer don't even know about this custom collection though as we've encapsulated its very existence.

We've tested CustomerAddressCollection but we want to test that Customer works correctly with it, and in this case we want to write an interaction/mocking test. It seems to me we have two choices:

1. Give CustomerAddressCollection an interface then allow it to be injected into Customer and use Rhino Mocks for the mocking.
2. Use TypeMock to mock CustomerAddressCollection, mock the methods that we expect Customer to access and then check Customer accesses it correctly.

For now I'm thinking the second option is better.

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone

The Domain And Testing Dependent Layers

I've blogged seperately about the arguments for mocking domain classes when testing the domain itself.

However we also need to consider how to deal with situations where we want to be able to mock out the domain when testing another layer, in particular we need to consider it because Ayende has just posted a good blog article that relates to the topic.

I'll take the example that I put in Ayende's blog. Lets say I have an application layer service that calls to a repository, then to an infrastructure service, then into a domain service/entity and then returns. I want to test the application layer service. In that case I can inject in the repository and infrastructure service to do interaction testing, but would you also inject the domain service/entity.

I think there are a couple of options:

1. Interfaces - On any domain objects we need to mock.
2. Virtual members - Any member we need to mock would be virtual.
3. No Domain Mocking - Don't mock domain classes when testing other layers.
4. TypeMock - Oh dear, into the lions den....

Interfaces

An interface on every domain object that we need to mock, sure its an option that some people go for but I'm with the group that argues you should only use interfaces in your domain if they are useful. I've blogged about this before but do I really want to be able to replace one Customer with another, probably not so its not a useful extension point to introduce and it ends up introducing complexity I don't need.

We've also gone for a pure (or as pure as we can get) persistence ignorant approach, so I don't want to then have to mess with my domain to get it to fit in with IoC and mocking frameworks.

Virtual Members

Interfaces are not the only way to mock domain objects, Rhino Mocks can mock virtual members too and since most of our aggregate roots are lazy loadable their members are virtual (NHibernate requires this).

This would seem to me to be a half baked solution, if we're going to mock why not use TypeMock.

TypeMock

It is a hugely powerful tool and you can misuse it. However in this case we'd have chosen to use it in a way that lets us maintain the design we want, which to me is an acceptable useage.

No Domain Mocking

Should be an option, why not let the Application layer service call into the domain service/entity.

Our domain is POCO and in fact very rarely calls out to the repositories directly. This isn't the way everyone goes as can be seen here and here.

We can get away with this thanks to NHibernate, in fact the only time our domain classes go to repositories to get reference data and when we go with that approach we hide it behind a Registry/Service Locator. By and large this works fine, where it doesn't we use a special coordination layer, part of the domain but with different responsibilities.

So using the domain should be simple.

Summary

So far we haven't needed to mock the domain classes when testing at a higher level, if we do I'm thinking that using TypeMock is a good option.

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone

TypeMock / Rhino.Mocks - Designing for testability

On the project I work on we use a combination of Rhino.Mocks and TypeMock.

I'd used TypeMock a lot in the past and found it to be superb and I have always been skeptical on the advantages of designing for testability when dealing with domain classes. TypeMock also helped me avoid having to look at IOC, simplifying my domain and the related infrastructure code.

However I decided to give Rhino Mocks a shot and I did find it useful, if you are prepared to accept the limitation that it can only do interfaces/virtual methods/delegates.

In general I decided to favor TypeMock and only use Rhino.Mocks where it fitted the design I wanted, for example I use Rhino Mocks when mocking out dependencies to infrastructure.

There's a lot of debate about the use of TypeMock though, some people seem to disagree with it:

http://vadim-net.blogspot.com/2007/04/typemock-too-powerful-to-use.html
http://weblogs.asp.net/rosherove/archive/2007/04/26/choosing-a-mock-object-framework.aspx
http://www.mockobjects.com/2007/03/stop-designing-for-testability.html

There are also a few people who seem to thing it is worth using though:

http://www.paraesthesia.com/blog/comments.php?id=1086_0_1_0_C
http://www.elilopian.com/2007/02/26/object-oriented-testable-designed-you-must-be-out-of-your-mind/

It’s an interesting discussion and I guess your take on it is affected by many factors including the types of systems you work on and where in the code base you’re working.

As an example in our application we have persistence ignorant domain assemblies (Customer/Order) and separate persistence assemblies containing the repositories (CustomerRepository/RepositoryOrder). Nine times out of 10 we can ensure our domain assemblies never need to access repositories by careful use of NHibernate's features, making the domain classes very easy to unit test.

However in some cases the domain objects do need to call out to the repositories, what should we do then? We need to make sure that what we maintain the ability to test the domain simply. We could have looked at IOC but instead I went for a simpler Registry pattern based approach. You pass in a RepositoryFactory to this registry during initializaiton (constructor injection) and the interfaces of the repositories (though not the implementations) are in the domain assembly (separated interface).

This works fine and because the repositories and the factory implement interfaces I can use Rhino Mocks. Superb, so I can create a mock repository factory and pass it to the registry and that factory will create mock repositories.

This is fine and is a good example of designing for testability. However we also have cases where one domain object (A) uses another complex domain object (B). When testing A we want to mock B but we're happy with the design as it is so we don't want to start shoving interfaces onto B or using dependency injection. In those cases I turn to TypeMock.

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone

TypeMock - Helps Improve Your Designs?

If anyone ever reads this blog, and if they've used TypeMock, then I'd be interested in what they thought of it. For those of you who haven't used it you should take a look if your doing TDD as it allows you to use mocking without redesigning your code.

For me the question is whether designing your code for testability is actually a good idea, if so using TypeMock too much is a bad idea.

Personally I'm much in favor of TDD but I think I disagree with most of the books/Websites because I don't think that decoupling your code to allow mocking necessarily results in particularly good designs.

Say I want to test a class that relies on a concrete Foo class . One way to get a mock Foo in for testing would be to create an IFoo interface, implemented by Foo and a new MockFoo class. To get the MockFoo into the class being tested I'd use something like IOC or a factory. An alternative would be to use NMock to create a dynamic mock for Foo, again its up to me to get the mocked object into the class being tested.

In the past I've tried doing this sort of decoupling for testability but my view is now that it adds unnecessary complexity. I also found that the interfaces/designs I was producing didn't necessarily decouple the software in ways that were later useful.

Thats where I think TypeMock is strong, I can use TDD to design the interfaces of my classes for normal usage and use TypeMock to mock out depedencies of the class being tested. Then once my class is in real usage I can look to decouple when and if its needed.

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone