BDD - What still confuses me

Although I have now begun to play with writing high level specifications with NBehave I must admit that I'm not getting much further with understanding BDD in general.

I thought I should put my questions into a blog post, I guess its more of a brain dump than anything else though.

Is BDD just better TDD?
Its tempting to view BDD as doing TDD well. In reality though there are lots of ways to practice TDD but BDD is slightly more specific, such as the way it drives for an outside-in approach.

Having said that I think you can use BDD without buying into the whole Mock Roles, Not Objects approach but it is interesting that BDD is pushing that style of working. I've tried it out and it can have advantages but unsurprisingly it also has some serious problems.

Outside In?
Outside-in can mean many things but I like the definition from XUnit test patterns. Anyway even if you do practice outside-in you don't necessarily buy fully into the approach where you start with the GUI (or slightly below) and mock your way to all your collaborators (as described at Wikipedia or Mock Rokes, Not Objects).

If you practice DDD then you probably focus on the domain early, often then using classicist style testing practices (I've blogged about this before). If you do use mocking its probably when testing services and your probably not using it to definite ISP compliant role interfaces (or maybe you are, is it working because I am interested).

I think you can also find value in outside-in testing but this time starting from the public interface to the domain/application. You can start with a high level test and then start using TDD for the details, as discussed here. Once all the code is written. That doesn't preclude you using Test Spies or Stubs where appropriate, but it does mean that you don't need to jump directly into mocking which can lead to fragile tests.

If you do believe in mockist style testing, defining collaborations and going from there, then the high level BDD tests are a good place to do it however because thats the place where you will be thinking of high level interactions between entities/services/factories and so on. Showing those interactions in the tests could have some value, though whether you extract role interfaces is another issue.

Having said all this I do think you need to be thinking about/defining the GUI at the same time as working on the domain model to avoid overcomplication. For example you may implement a complex object hierarchy in the domain when for this version of the software something simple would have done. I've been bitten by this before, but I also think that starting from the GUI and working downwards is not the way to define a domain model. In my experience you usually need to do both GUI based work and domain work early on.

There are smart people who use outside-in testing in ways that I have no experience of (see this TDD thread which was a real eye opener for me, emphasizing just how differently people tackle testing/design).

High Level or All Levels?
For me the most exciting idea is writing high level BDD tests for two primary reasons:

1. Stories - Lower level tests are less likely to be driven by stories from the stakeholder.
2. Refactoring - High level tests are the ones that will provide benefits because they will be more immune to refactoring.

So can you use the same style for lower level specifications, I guess so but I haven't tried it yet and I'm not sure that it will work quite as well. If you do use it for your lower level specifications then I'd question whether a framework like NBehave is the best choice:

listStory
.AsA("developer")
    .IWant("my list to behave correctly when items are added")
    .SoThat("I can use it in my software");

This obviously isn't how you'd do it, but I'd be thinking that if you do use BDD at this low level then you are perhaps better just writing BDD tests without using something like NBehave (as shown on the wikipedia article of ListTest and by Jimmy Bogard in Converting tests to specs is a bad idea).

Can you use BDD for infrastructure/integration work?
NOTE: Here I'm talking about higher level (Scenarios, or Application Examples) specifications.

Ultimately everything you do is user driven but some problems make it difficult to tie your work back to a story.

For example my current project is an integration with an external system. This is quite a lot of work and defining user stories can be tricky as the users are not going to be interested till the integration is complete. Thanks to some brilliant help on the XP forum, not least Simon Jones' post, I've managed to get user stories to work for such a task but it does involve a little bit of work.

However for such a project do BDD tests make sense? Take the current piece of this project, a Windows Service that the users don't even directly use. I'm trying to use NBehave specifications but it can get a little odd, for example using the NBehave syntax who do I specify in the "As A" part of the story? Really the users don't even care that the service exists, but to be fair for this sort of work I'm happy to think outside the box a little and I think thats fine.

So yes I do think high level specifications can work for infrastructure/integration tasks.

Based On User Stories?
We use user stories and so the idea of writing the high level specifications based on user stories is attractive and I think it is a valid approach.

It is worth noting that whilst behaviour-driven.org seems to indicate that use cases are a good source whats-in-a-story does explain that its just as applicable where other requirements techniques are used (which is to be expected).

BDD and the Ubiquitous Language
I originally thought that BDD aimed to define, or help in defining, the (DDD) ubiquitous language. Its hard to know though so lets look at how BDD is linked to a ubiquitous language in some of the main articles:

1. Wikipedia - "Behavior-driven developers use their native language in combination with the ubiquitous language of Domain Driven Design". I have no idea what this means, is it using the DDD ubiquitous language in the tests or are we saying that BDD is forming ubiquitous language for writing specificatons?
2. Introducting BDD -Here BDD is the "ubiquitous language for the analysis process itself".
3. Whats in a story -No mention.
4. behaviour-driven.org - "It aims to help focus development on the delivery of prioritised, verifiable business value by providing a common vocabulary (also referred to as a UbiquitousLanguage) that spans the divide between Business and Technology.". This seems to indicate that your BDD specifications are supposed to look use the ubiquitous language.

As far as I can see there is absolutely no consistency in what the different sources of BDD mean when they talk about the ubiquitous language. I also think that taking the term ubiquitous language and using it outside of the context that DDD provides is unnecessarily confusing.

So what if the specifications are written in the ubiquitous language?

NOTE: This discussion only really applies to the higher level tests against your domain model, I don't think lower level (implementation detail) or infrastructure tests are going to be written in the ubiquitous language.

As discussed before according to behaviour-driven.org BDD:

...aims to help focus development on the delivery of prioritised, verifiable business value by providing a common vocabulary (also referred to as a UbiquitousLanguage) that spans the divide between Business and Technology."...

This sounds good and if I'm writing the tests then I will use the ubiquitous language. However if I'm doing BDD properly then I'll have others involved:

1. BDD Process - "A SubjectMatterExpert (typically a business user) works with a BusinessAnalyst to identify a business requirement"
2. Whats in a story - "the stories are the result of conversations between the project stakeholders, business analysts, testers and developers. BDD is as much about the interactions between the various people in the project as it is about the outputs of the development process."

So my question here is whether I'm expecting my user stories text to be written by people outside the development team? If so is it the users or the domain experts? If it's the former then I do not expect them to be in the ubiqutous language, if its the latter then I would.

As discussed above my own view is that in many cases user stories will feed into the BDD specifications. So do I expect user stories to be written in the ubiquitous language, not really and for these reasons:

1. Different Audiences - Our users are not necessarily our domain experts and even if some of them are we probably have some who are not. Having domain experts write the user stories is not good (been there, done that) and having the users define the domain model is no better (too simplified). I thus think that expecting the users to understand the ubiquitous language, which probably has little to do with their day to day job, is unreasonable.
2. Clutter - Stories are there to specify the behavior the user wants. With this in mind I'm not sure that cluttering them with domain model details is any more useful than including GUI details in them. Does a user care what model you put in place, probably not and I'm not sure we should expect them to.
3. Evolving Language - You are also likely to evolve your ubiquitous language as you learn more about the domain, probably resulting in it becoming more complex. The question would then be whether you build this complexity into the user stories, I'd argue that doing so will just confuse things.

Thats the way I see it for user stories and offhand I can't think why this wouldn't apply equally to BDD. So I'm not seeing BDD affecting our ubiquitous language all that much, I think instead when writing user stories we should aim to use the language of the users.

Obviously if your domain experts are involved in writing the BDD specifications then using the ubiquitous language will be more attractive.

Anyway Greg Young has two superb posts on this namely BDD and the Shared Language and BDD and the Shared Language: The Stakeholder.

So In Conclusion...

BDD is many things to many people and although some people are trying to tie it down I'm not sure it will work.

Unfortunately although I think it is positive that there are so many ways to describe BDD I do find that in some cases (ubiquitous language) it is unnecessarily confusing.

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

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

Domain Oriented Messages

Greg Young has a great post titled Mocks are a code smell.

As he explains the title is to grab your attention and although he does see mocking being overused, which is definitely my view and seemed to be the general feeling at the mocking session ALT.NET UK, the post itself covers a very interesting way of handling communication within the domain.


To be honest Greg's ideas and implementations of this pattern are more advanced than mine, and I know he uses it a lot more in his designs that I do, so I'm looking forward to reading his other posts on this topic.

Trying It Out - Start Simple

If you're daunted by the idea of going to a messaging approach then you could always start simple.

As an example I would say that what Greg is suggesting is just a more advanced version of the approach that I intend to use for dirty tracking within our domain. Messages are generated when domain events happen and these will be registered with a service that you get from a service locator.

This makes testing simple as you can just use a test spy (same approach as Greg seems to be using) but is also a design that I like in terms of lowering coupling.

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

Infrastructure Ignorance

The AMC affecting design thread on ALT.NET has triggered a few other threads. Ayende and Jeremy Miller have their own posts discussing why your business code should be ignorant of IoC, something I fully agree with.

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

Justifying Our Designs [IoC/DI/AOP/Auto Mocking Contaner]

There was an interesting thread on the ALT.NET forum called "AMC: Changes to the way we think".

Now I don't use the auto-mocking container so it hasn't changed the way I think but I did want to comment on some of the ideas on the thread.

Should We See All Dependencies In The Constructor?
A lot of people seem to think that seeing a classes dependencies in its constructor is important, the argument being that seeing this tells you a lot about the design of the class.

This is a compelling argument and to some extent I agree with it but it misses one key point, not all dependencies are created equal. A dependency on, for example, a domain service or a repository tells me more about how a class works than a dependency on a logging/dirty tracking service. The first is a meaningful part of the design, the second is just an aspect of the implementation.

You could also say that seeing all a classes dependencies doesn't necessarily tell you much about how it behaves, to know that you need to see its own behavior and the way it uses those dependencies.

I'd also say that this is a case where people argue about the improvements in design when in some cases we are only doing what we are doing to fit in with the implementation constraints of the tools we use. We need to pass the dependencies in so we use constructor injection, to mock we need interfaces (or virtual members) so we end up injecting interfaces. The end result is very decoupled but is it useful decoupling, if we started from scratch and did the simplest thing that can work (YAGNI) would this be the design we'd come up with? Probably not...

AOP
Dependencies from the domain, Ayende indicates that he prefers his domain classes don't depend on non-domain services.

I buy into this too but for things like dirty tracking of domain classes it can get difficult but this is where AOP can prove useful, in those cases you're domain classes might have a run-time dependency on non-domain services but I think this is perfectly accessible. We can also probably use test spies for these sorts of dependencies, which makes for conveniant testing.

Testing
To me the auto-mocking container is a good idea but two things worry me about it.

The first is that it couples your tests to IoC, which when I first read about IoC was seen as a bad solution. I guess you can put up with this though.

The second issue I have with it is that it hides the dependencies that aren't important to the test. It seems like we've exposed the dependencies in the constructor to allow IoC and to allow replacing them in tests. However this makes the tests harder to read so we introduce a component to fix that issue. It just seems like it might be worth taking a step back and re-evaluating before you use the AMC, after doing this you might want to go ahead and use it of course :)

"Bad Designs" Can Work
So our domain classes have few dependencies other than on other domain classes (not on any services outside the domain). Where there are dependencies they are through an interface to the service, you get the service from a Service Locator.

However have layers above this, including a coordination style layer that talks to repositories and the rest.

So how do we get the repositories and infrastructure services into the services in the coordination layer, choices would be:

1. Extracted interfaces passed in to the constructor of the service - Pass in an ICustomerRepository (or rename the interface to give it domain meaning).
2. Pass concrete classes into the constructor of the service - Pass a CustomerRepository in.
3. Make the service methods static but pass in the dependencies.
4. Get the required services from a Service Locator.

Which do we do, none. The service methods are all static and when one of these domain coordination services needs a repository/infrastructure service it just creates it.

Its not as decoupled as we could make it but it's clear and simple and the layer in question is quite thin. If we needed to decouple we could without much effort and so I'm quite comfortable with the design we have.

What I'm trying to say is that I sometimes think people take things too far and that sometimes you can couple things safely. Maybe tomorrow you will need to rethink, but maybe not.

This doesn't mean that I don't rate IoC/DI or decoupling in general, I do. However I like to be able to decide for myself how far to take it.

Coupling Code To IoC
This was one of the original suggestions and I don't particularly like it. If you don't want to see the dependencies passed in to the constructor then I'd say you should use a Service Locator (which could in turn call out to a container) or use the hub service style approach.

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

Object-Object Mapping

We're starting to do a lot of mapping between domain classes and other forms, so far mainly so that we can export representations of our domain objects to external systems.

Performing the mapping quickly becomes a real pain and testing the mappings is even worse.

I don't think there is much you can do about the dullness of the testing, but I have been looking for a framework that will make the mapping easier and on an ALT.NET thread on the topic someone suggested I look at a little library called Otis.

So far I'm very impressed so here's what I've found. If you want to know more download the binaries or source code, the advantage of the source code is that it has a sample with it. The WIKI also has good information but I wanted to write what I've found so far, mainly to remind myself.

Mapping Files

I think I'm going to use the XML file approach as its cleaner, I've name the files "*.otis.xml" and made them "Embedded Resources". I also setup the XSD that you get with the binaries to give me intellisense which is very useful.

Lets look at a simple example:<br /><?xml version="1.0" encoding="utf-8" ?><br /><otis-mapping xmlns="urn:otis-mapping-1.0"><br /> <class name="MappingSpike.UserDTO, MappingSpike" source="MappingSpike.UserEntity, MappingSpike" ><br /> <member name="Id" /><br /> <!-- maps to the member with the same name --><br /> <member name="UserName" expression="$TheUserName" /><br /> <member name="Advisor" expression="$Advisor.Name"/><br />This shows the following:

1. UserEntity.Id -> UserDTO.Id
2. UserEntity.UserName -> UserDTO.TheUserName
3. UserEntity.Advisor -> UserDTO.Advisor.Name

As you can see the mapping is written from the standpoint of the source class, once you get this its quite easy to follow.

You can read more about the mappings here but the sample with the source code is also good.

Configuration

To get the same to work I had to using the following C# code:

Configuration cfg = new Configuration();
cfg.AddAssemblyResources(Assembly.GetExecutingAssembly(), "otis.xml");

IAssembler dtoFromEntityAssembler = cfg.GetAssembler();

UserEntity entity = new UserEntity(5, "Bob Dole", "bdole");
entity.Advisor.Name = "sdaddds232";

UserDTO dto = dtoFromEntityAssembler.AssembleFrom(entity);

This allows me to do a one-way mapping from the UserEntity to the UserDTO.

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

AOP and the Domain - Aspects of Domain Model Management

Finally got round to reading Mats Helanders InfoQ post Aspects of Domain Model Management.

The article is very long, with a lot of content being around hacky solutions to the problems that the author is delaing with (attaching non-business logic to the domain).

I read all of the article but if you get bored you can skip most of the middle bit right up to Using "Aspect Oriented Programming".

The bit on proxies is interesting, if you're using NHibernate then you are already using the Infrastructural Proxy Subclass approach for lazy-loading (and collections) so you should be familiar with it. However trying to use that approach to handle your own requirements is not going to be clean or transparent.

Back to AOP. The author uses his own NAspect framework for run-time AOP however we were thinking of using PostSharp as compile time seemed good enough and it is more transparent. Having to use abstract factory, or just factories, for all object creation just does not appeal though.

The attribute based approach is cool though, and its similiar to the way you attach behavior with PostSharp . All in all I think I'm going to plow on with PostSharp and then see how it goes (as described in my post AOP and the Domain - Dirty Tracking).

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

Team System and Agile - Do they go together?

I blogged about this a while ago but we've been trying introduce a user story based requirement process, our user stories would be stored in TFS and the users would access them using the Web Access Power Tool (previously called TeamPlain).

Sounds good, especially as the tool is free. Problem is every single user who wants to use the web portal to access TFS is going to have to have a CAL. I've complained about this before, and even logged a bug with Microsoft about it, but really it doesn't seem like they understand how big a problem this is.

Given the situation I would truly question whether any company should consider using Team System unless they are also prepared to hand over large sums of money to get their users involved. If you decide not to use TFS for artifacts such as user stories then its really just an expensive source control system.

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

Scrummerfall

Jimmy Bogard, who is becoming one of my favorite bloggers, has two excellent posts on Scrummerfall here and here. If you are "doing agile" but finding its only really changing the development team then they may be relevant.

To be honest we don't do Scrummerfall, we didn't start out with Scrum.

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

Developer Testing - Discussion at ALT.NET UK

I thought I'd blog about some of the topics that were discussed at ALT.NET UK, or more correctly my views on those topics.

Styles Of Testing

I've blogged about the fact that I tend not to use interaction testing much. I find interaction testing can result in overspecified software and sometimes in tests that are hard to read. To be fair some of this could be countered by better use of mocking, for example diffrentiating between mocks and stubs (or Stubs and Expecations if thats the terminology you prefer), but state based testing is still my preferred approach especially for the domain model.

In the disucssion of mocking at ALT.NET UK it seemed that most of the attendees agreed that we are now overusing mocking. Whilst there was little disagreement with the idea of stubbing/mocking in some situations (e.g. between layers or domain modules) most people did seem to think it was dangerous if not used carefully.

Ian Cooper has blogged about this topic too.

Granularity

What granularity to test at, something that constantly irks me. To some people unit testing is always testing a single class, I've always thought that you can use unit tests for (small) groups of classes. In particular I do this when I have a helper class that I've extracted out of the class I was previously testing.

There are advantages and disadvantages to testing groups of closely related classes together though. The main advantage (especially early in design) is the tests can withstand refactoring and the main disadvantages are that they can be more complex and don't have such good defect localization.

Anyway Ian Coopers blog entry sum up my views on this entire topic. We also discussed whether to move/copy the tests down to the extracted class when you use extract class refactoring.

I'm totally inconsistent on this, I sometimes test against the extracted class and sometimes leave the tests at the level of the class I extracted it from.

Design For Test or Design For Design

The topic of design for testability came up a lot, though not in the way you might expect!

I've never believed design for testability is necessarily a good idea, I've blogged about this topic in a couple of posts before including here and here.

I don't believe there is any good substitute for thinking about your design. Sometimes designing for testability, especially if you favor lots of mocking using a traditional mocking tool, does bring lots of decoupling it's not necessarily as good as focussed decoupling.

Anyway I knew Roy Osherove was no longer recommending designing for testability and so was expecting a lot of disagreements around this topic. In actual fact though there wasn't much disagreement on the topic.

End To End Testing

At one session Tana Isaac discussed Watin which can be used to write tests for your GUI. The discussion covered whether GUI testing is a good idea because it can be more trouble than it's worth. However Tana pointed out that the tests they are writing are not only acting as good specifications but are not at all flakey and indeed are rarely being modified.

Others also mentioned the Web testing functionality in VS 2008, which apparently is far better than what was in previous versions.

The general discussion fitted in with the contributions that Nat Pryce made to an interesting TDD thread. Nat sums up the way he tests in this post.

All in all myself and John both came away thinking that we needed to look more at Watin and end-to-end testing in general.

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

BDD - I think I'm finally getting some understanding

Nick Hines from Thoughtworks led a really good session on BDD at ALT.NET UK. The session clarified a lot of things for me, though as always after a bit of thought I am left with plenty more questions so I thought a blog entry was in order.

What Is BDD
My initial experience with BDD was Dave Astels doing a videocast about it. Better TDD and focussing on design were the name of the game. This made sense but when I started looking into it more I got a bit lost. The documentation seems to focus on the influence of DDD and the use of interaction testing. This confused me a bit as unless you practice need-driven development its questionable whether you are using interaction design as a domain design technique. I was also confused as to how BDD fit in with DDD, other than both sharing the idea of a ubiquitous language.

Anyway the discussion clarified the fact that its fair to view BDD as better TDD and it has little to do with need-driven development (though I guess you could use them together). It also doesn't specify that you must be using interaction testing.

Where to use BDD
We also came to the conclusion that these tests were quite high level, more influenced by users (user story acceptance tests) or a business analyst. I'm thus not clear that they would influence the domain design other than at a shallow level as your users are normally not your domain experts. This is probably what Greg Young means when he talks about BDD being used to for a shared language which may be distinct from the ubiquitous language.

Practically this probably means writing these tests against high level domain entities or your application/service layer. The discussion did cover whether you then take the BDD tests into the domain and indeed right down to hidden implementation details. I'm still not clear on this but if we are using BDD tests as specifications then starting out with detailed high level specifications isn't a bad idea, it gives us a good way of specifying acceptance criteria.

More Questions
The question is then how detailed to make these high level BDD tests. They have to be quite detailed and comprehensive if they are acceptance tests but if you make them too comprehensive then you are going to end up testing the same things at multiple levels, initially with a high level BDD test then with more detailed "unit" tests.

This seems attractive to me though, Jimmy Bogard has a great post about how he tried to make sure his BDD tests are somewhat immume to refactoring (changing implementation).

Other Links
Ray Houston is one of many people blogging about learning BDD, including this really interesting post.

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

Test Spy - Replacing Services When Testing The Domain

At the recent discussion of mocking at ALT.NET UK we discussed using test spies.

We actually make good use of test spies now and they have some advantages. Let me give you an example where they come in handy. Our domain classes occassionally need to contact external services, interfaces implemented by these services are put in the domain (seperated interface) with the implementations available to the domain using a Service Locator.

What do to when testing though, we have maybe 1% of the the tests where we need to setup a mock version of the service and the rest don't care about the service so they can run with a do-nothing stub.

However if we register a mock version of the service with the Service Locator and if we forget to cleanup propely then that mock service will affect other tests. Its also painful having to put the stub service back in after you are doing using the mock.

The solution, suggested by one of my colleagues, is simple. We don't ever mock the service but instead we use a test spy. We register the Test Spy with the Service Locator in a method tagged with AssemblyInitializeAttribute so it gets run before any tests in that assembly.

All the normal tests run normally, and if they in some way cause the system to interact with the test spy then the interaction happens totally silently, for example maybe the test spy logs the interaction by adding an item to an internal collection.

So what about the 1% of the tests that really want to test against the test spy (the tests that might otherwise have used a mock). Well in the test fixture initialization we reset the test spy then at the end of each test we ask the test spy what calls it received and verify that they were what we expected.

This works a treat, really simple solution that makes the tests very easy to write.

NOTE - When to call services from the domain
The comment from Andreas made me realize that I didn't say when I think a domain class should talk to a service.

Normally I avoid these sorts of dependencies in order to keep the domain code clean, simple and easily testable. However for cross cutting concerns like logging/dirty tracking an AOP based approach (see my PostSharp posts) where we introduce the code that calls the service is very clean.

In particular this works because for those cases we can have the domain class contact the (infrastructure) Service but we don't care about any return values, hence the applicability of a Test Spy.

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

Working Effectively With Legacy Code

Although I've owned a copy for well over a year I've never felt like reading Working Effectively With Legacy Code but having just finished reading an excellent chapter I'm realizing this was a mistake.

As you probably know the book is really about getting code under test, legacy code being code without tests. Thus if you are working with a codebase with little or no test coverage, and where dependencies make it hard to test, it's going to be a very useful book.

Since we already have good test coverage and generally don't have any major problems getting our code under test I didn't think it was that relevant. However I just read an excellent chapter (6) that explains how to make changes to code that doesn't have tests whilst ensuring that your new code has tests. The chapter documents a few patterns:

1. Sprout Method - You cannot get the method that you are adding the behavior to under test. Put the new behavior into a new method with its own tests, call the new method from the method you want to add the behavior to.
2. Sprout Class - Perhaps you can't get the existing class under test or the new responsibility does not fit the existing class, create a new class for the new behavior. Hopefully by doing this you improve the design and have extracted a meaningful concept.
3. Wrap Method - Take the existing method and extract the code from it into a new method, leaving the original method calling the new one. Now add a call to the new method that adds the behavior you want to add. This maintains the interface used by the callers.
4. Wrap Class - Extract a decorator or a wrapper class that delegates to your existing class but adds behavior before/after the call(s). The book recommends using decorator sparingly but its useful when there are many class to the class being wrapped.

The book then goes on to compare the choices.

Like I really liked the section. It focusses on changes that allow you to get your code under test but they could be part of a process that eventually improves the design and brings your entire code base under test.

I also like the fact that he has given these changes simple memorable names, and for that reason alone I'm now glad I've started reading the book.

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

TDD Newsgroup - Interesting Threads

I've started to read the TDD newsgroup, which is great, and I thought I'd begin to keep track of threads that I've found useful:

• Extract Class and TDD - I use refactoring a lot so I often end up with (hidden) extracted class that are only tested because the code that uses the extracted class is tested. This thread covers whether this is appropriate. I partricularly like the Method Use Rule post. Anyway my feeling after reading the thread is if I'm extracting to remove duplication then I should tested the extracted class itself, otherwise leaving the tests I have is a valid use. I'm also thinking that any class that is to be part of the ubiquitous langauge should always have its own tests, so even if you extract a specification and only use it once it needs to be tested in isolation.
• Refactoring - Covers some of the same ground as the Extract Class and TDD one.
• Mocking Concrete Objects - What I took away from this is that if you have an inteface, or if you think you can add a meaningful interface, then mock that interface if it suits. If you have a concrete class and don't want to add the interface then use real instances.

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

Styles Of TDD for your Domain Model

Having read a lot of mockobjects.com I'm beginning to understand need-driven development and the effect on design. This has made me want to re-read some old articles:

• Styles of TDD: Left, Right, and Center - David Laribee builds on Martin Fowlers Mocks Aren't Stubs article. Reading it I guess I'm "Middle of the Road" when it comes to state v mocking. When thinking about our POCO domain I use the classical approach for entities and value objects, but as he says when you get into use services you can use mocking.
• TDD Design Starter Kit - State vs. Interaction Testing - Jeremy Miller covers some of the same ground. The example where everyone would stub or mock but the bit at the end, which is in response to Martin Fowler, is interesting.
• A sign you're mocking too much - J. B. Rainsberger's covers why he never mocks value objects, rarely entities but feels its fine for services.
• Mocks Aren't Stubs - Great article.

These are all good posts but I'm coming to the conclusion that there just isn't that much real content out there about how to use interaction testing as a design and testing activity for domain entities/value objects. Seems like a lot of people don't do it and so far the ones that do haven't written that much about it.

The content I have found has semed to be producing designs that I wouldn't be that interested in and although the idea of extracting role interfaces from high level domain entities interests me I can't find any real evidence that people are doing it meaningfully. I'm also not sure that doing it is going to improve the design that much.

Anyway I think for now I'm better focussing my design efforts on traditional DDD activities, whilst keeping an eye on what the BDD/mockobjects.com guys produce.

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

Johns New Blog

A colleague of mine John McDowall has a new blog. Its not as good as my blog but it may be the second best blog in the world.

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

Interesting Posts About Tests Influencing Design

Oddly I started reading a post by Jay Flowers, which led me to re-read a linked post at mockobjects.com which in turn led me to the most relevant post of all about testing domain classes. I'm glad I followed the links because there is some good info in these posts.

Shifting The Focus
Jay Flowers is thinking about testing and design at the minute too and has just posted about how it affects design in a post called Shifting The Focus.

Test Smell : Everything Is Mocked
I read the post Test Smell: Everything is mocked some time ago but never blogged about it but I do definitely think its worth reading.

I fully agree with the post, directly mocking external API's is often going to be a mistake and your better to use TDD to evolve a wrapper. I also think mocking value objects is a bit of a no-no.

Note there is a TDD thread related to mocking value objects.

Testing Domain Classes
J. B. Rainsberger has a post called A sign you're mocking too much which I whole heartedly agree with.

One of the main points in the post is summed up in this line "Never mock values, sometimes mock entities, but mock services freely". I agree with this and that's basically the way I test domain classes too:

1. Value Objects - No reason to mock, they should be simple to construct.
2. Entities - I tend to create real instances using Object Mother or Test Data Builder objects. Occassionally I'll stub an entity but very rarely will I mock it.
3. Services - Mock away, including mocking repositories.

This also ties in nicely with Eric Evans' opinions from the Testing The Domain thread on the DDD forum. It also indicates that some DDD practitioners (including myself) are using TDD to influence design in ways other than those that we would get to if we purely used interaction testing.

I think I'm going to start to focus on looking at our domain tests and object mothers to see what they are telling us about problems with our current designs.

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

How You Test = How You Design

I've recently started reading through all the design related posts at mockobjects.com.

They are highly recommended and I agree with all of the theory behind them and a lot of the practices. However what interested me most was that despite this I don't design software in the same way as them.

Take the "Test Smell: I need to mock an object I can't replace (without magic)" post as an example. I love the design exercise that the author goes through, and extracting the Clock/SameDayChecker class is superb. Yet something about it made me realize that I don't design the way they do and amn't sure I want to...

Refactoring v Need To Mock
In the example the design improvement is driven by the need to replace the time in a test.

Now I can understand the need to replace the time but I would also say that if your the sort of designer than looks at the original code and sees that its not cohesive enough then your going to extract the SameDayChecker concept regardless.

Maybe I'm wrong though, would I have looked at the original code and thought "good enough". Possibly, and if there was no pain then that might have been fine. So the tests have perhaps forced us to a better design.

However that leaves me a little cold as if we didn't need to replace the time for testing, or if the incohesive code had nothing to do with an external dependency, then we'd have settled for the first option.

If we thus use this style of testing to drive our designs then we only get good designs if we make every piece of the code replacable...

Injection
I dunno but to me the whole IoC thing is heavily influenced by Robert Martins ideas of dependency inversion.

Thing is I don't think Robert Martin meant that every class should be replacable, or at least I never read it that way.

I also don't think it should be used as your primary design technique, as in I want to test Customer without CustomerMustHaveAddressRule so i'll extract the rule (good) then inject it into Customer (huh). Do I really need to inject my rules into the domain, if I do then fine but for many line of business applications this would be overkill.

My approach would be extract the rule (SRP/cohesion etc.) but then use it directly from the domain. I'm unlikely to replace one rule with another implementation.

Why It Matters
I actually think using interaction testing as a design technique is interesting but when I look at the Clock/SameDayChecker example I'm left a little unhappy.

Am I really going to ever replace the SameDayChecker in production, is it really a meaningful dependency that I want my domain class to show. To me the answer is "probably not" to both.

I also think that IoC and injection of dependencies is great. However I definitely do not think everything needs to be injected when it comes to domain models, and if you use the design technique described then I think that you could end up with decoupling that I wouldn't find useful.

Lots of decoupling, much of which does nothing but make the design more complex without ever being taken advantage of, is my worry with some of these techniques.

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

TDD Anti-Patterns

In comments to one of his blog entries Jeremy Miller linked to this good post on TDD Anti-Patterns. Definitely looking forward to the paper that the author of the post is writing.

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

Test Doubles and the Effect On Designs - Mock/Stub/Fake

Just got through reading the mockobjects article on the interaction test smell too many expectations.

It's a great article and made me want to try to bring together my understanding of what people mean when they talk about stubbing and mocking.

MockObjects.com - Stubs and Expectations
The article makes the distinction between Stubs and Expectations:

1. Stub - Replace a dependend on component (DOC) so that you can get it to return known values.
2. Expectation - Goes further by testing that we get the expected interaction with the DOC.

The idea is that if you program too many expecations into the test you get confusing tests that don't make it clear whats important.

XUnit Test Patterns - Stubs and Mock Objects
If you have read Meszaros's XUnit Test Patterns then you will know that in his view there are multiple types of Test Double and they are required to control two things:

1. Indirect Inputs - If the system under test (SUT) uses the DOC and the DOC returns any values (even exceptions) that affect the SUT then you need to be able to make the DOC return these values in order to run your tests. If you can't get the DOC to do it then you replace it with a Test Double.
2. Indirect Outputs - Encapsulation often means we don't have to care how an object does what it does, however when testing we do care and we therefore may want to test the interactions with the DOC (in the process writing the SUT to make its dependency on the DOC more obvious). In fact in some cases we may have no choice if the DOC does not produce any observable side effects.

Meszaros goes further and describes the means of getting the correct inputs into the SUT in as being through a control point and the means of verifying the indirect outputs as being through an observation point.

In Meszaros's terminology there are thus three main types of Test Double:

1. Test Stub - Controls indirect inputs to the SUT.
2. Test Spy - Acts as a Test Stub but also records calls so that the test can examine them.
3. Mock Object - You pre-program it with the expected interactions and it will verify they happened.

Meszaros also discussed further classifications and how to configure/install the Test Doubles, as with the rest of the book it is very comprehensive.

Why It Matters
It seems like people are coming to the conclusion that it is important to differentiate between situations where you care about the expected interaction with an object and cases where you don't. If you don't make the differentiation your tests will be unnecessarily complex.

The interesting bit is then how the different types of Test Double affect your testing. I believe many people use Mock Objects when they really don't much care about the collaborations and aren't using the mocking as an aid to design. In fact the mock object is often simply there to replace a DOC so that we can simplify or speed up the test. This is at odds with the design technique that mockobjects.com and "Mock Roles, Not Objects" are recommending. As I understand it they view the outside-in process of design as being a big advantage of using interaction tests and use that to drive their designs (Need-Driven Development).

Its the second issue, how tests affect design, that interests me at the moment.

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

Posting C# Code In Blogger

Gary Murchison was good enough to send me to the C# Code Format Website, John McDowall (another colleague) was good enough to work out that in order to get the content into Blogger correctly you need to either put all the content into one line (Notepad++ to the rescue) or switch "Convert line breaks" to false.

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

Interaction Testing of Service Collaborations

I decided to try to follow true interaction testing guidelines and use it as a design technique, specifically a technique to elicit roles and ISP compliant interfaces for DDD SERVICES.

At the minute I'm looking at how we can track changes to our domain objects so that we can report them (where appropriate) to external systems. We've decided to try using PostSharp, applying attributes to classes/members and the attributes will then cause the appropriate code to be inserted.

Interaction Test Driving The Initial Design
In my experience starting a large piece of work like this can be tricky. I've done some prototypes on using PostSharp and we basically know how we want the design to proceed.

To get me started though I need to write a high level test of this form, I decided to make it an interaction test and use TypeMock:

    [TestMethod]

    public void CanTrackCustomerActivation()

    {

        Customer customer = CustomerObjectMother.CreateProspect();

        DomainChangeMessage expectedMessage = new DomainChangeMessage(customer,

        "CustomerActivated");

        #region Mocking

        Mock serviceMock = MockManager.MockObject(typeof(IChangeTrackingService));

        serviceMock.ExpectCall("EventOccurred").Args(expectedMessage);

        IChangeTrackingService service = (IChangeTrackingService)serviceMock.MockedInstance;

        Mock serviceLocatorMock = MockManager.Mock(typeof(ServiceLocator), Constructor.Mocked);

        serviceLocatorMock.ExpectAndReturn("GetChangeTrackingService", service);

        #endregion

        customer.Activate();

        MockManager.Verify();

    } 

This test shows the following:

1. We'll have a service of type IChangeTrackingService and we expect its EventOccurred method to be called.


2. We expect the service to be retrieved from the existing ServiceLocator class (we considered using IoC but for now this will do, YAGNI).

Most importantly the test has helped us explore and confirm the design (see below) and although I'm not always made on interaction testing I think this one was useful.

To get the test pass all I need to do is put this sort of code into the Customer.ActivateMethod:

ServiceLocator.GetDomainChangeTrackingService().DomainEventOccurred(new DomainChangeMessage(this, "CustomerActivated"));

I'd refactor this code, but its a strarting point.

I need to make DomainChangeMessage a VALUE OBJECT to get this to pass (override Equals particularly). It was also nice that testing the changes I needed to make to DomainChangeMessage to turn it into a VALUE OBJECT (particularly overriding equals) was easy because I've written a helper class to deal with this in the past.

Importance Of The Test
In this case I'm happy that the test I created is very readable and shows clearly what the high level collaborations are.

The effect of this test on the design is subtle. I'd have designed this the same way regardless, the seperated interface (IChangeTrackingService) approach is one that works quite well and it's clear that DomainChangeMessage should be a VALUE OBJECT. However proving that this design is sound using an interaction test is valuable.

The next step is to write a test that actually checks that with a real instance of the SERVICE you get the correct behavior, which in this case might be just to save the DomainChangeMessage and make it available for use in the verification part of the test.

Oh but....
This is a bit of a cop out, every test that shows interaction testing uses it to get the role for a service style class.

What I'm really interested in is seeing how people use the same approach for domain ENTITIES, I'm not so sure that the ISP style interfaces you'd extract from them in order to get these tests to pass are so useful.

I'm prepared to be convinced though and the mock objects do seem to indicate that they think this approach can work for domain entities so I'm interested to see what they come up with.

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

DDD with AOP and DI Presentation

A new DDD thread links to a talk about using AOP and DI to support DDD. The talk itself is very interesting, not sure I agree with all of it but it is good.

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

BDD/TDD - What Drives The Domain Design

In view of the discussion of BDD[1][2] I've started to look at the way we specify/test our domain model. A great promise of BDD is that your tests will drive the design of your domain model and that the tests themselves will help explain the design of the domain.

My efforts to get to the essence of BDD have left me very confused and in an effort to better understand BDD I actually went to the Test Driven Development Yahoo group. I've been subscribed to it for a while but I'd never realized how good it is. Well informed discussion and heavyweights like Ron Jeffries/Kent Beck wading in. Great stuff and seems to me to have a similiar feel to the DDD group.

Anyway I came across one particularly useful thread. It doesn't really cover BDD directly but it does cover state/interaction testing and how they influence the way you design. In particular it contains a couple of great posts including this one which tries to get the to real essence of interaction and state testing and the way they affect your design.

I was already well aware of the difference between state and interaction testing but this single post summed things up very nicely and reminded me of a few things.

Personally I refactor, including to patterns, a lot. As I do I find my code changes massively which affects the way I test. Let me give you a representative example...

Example - State Testing/Refactoring Driving The Design
We need to allow people to debit Accounts in our system, a test to kick off this work might be

Account sourceAccount = ...;
Account targetAccount = ...;
Money amountToDebit = ...;

Money originalValueTargetAccount = targetAccount.Balance();
Money originalValueSourceAccount = sourceAccount.Balance();

FundsTransferService.Transfer(sourceAccount, targetAccount, amountToDebit); // code under test

Assert.AreEqual(originalValue - amountToDebit, account.Balance);

I'm not saying this the exact test I'd start with but its representative of the sorts of tests I'd be writing. This is a pure state test and in Ron Jeffries terminology is testing functionality not sequence.

As I go I'd be writing more and more tests and more and more code. As I went I'd refactor and after a while the method may be delegating to Specifications, Rules, Method Objects, Strategies, Entities, ValueObjects, Factories and other classes to do its work.

Some of the new classes will merely exist to ensure the code reads well (pure fabrications in Larman terminology).

As I extracted these pure fabrications I probably wouldn't change the tests, leaving them at the level that they started at (FundTransferService). I could change the tests to be tests specific to the new rule though. I'd just extract the code, ensure the tests passed, refactor the tests, ensure they passed...but then pure fabrications are very much open to redesign at any time so I'm not sure it makes so much sense to write tests for them specifically (questionable?).

Anyway what this means that I'm doing top down development (starting at public interface to the domain) but I'm not using stubbing or interaction testing, instead I use state testing and evolve the code and refactor a lot until I'm pretty happy.

Alternative - Interaction Tests Driving The Design

So the question is what is driving me to change the design, if I was doing proper interaction testing then I would be defining the interactions and then writing the code to fulfill it.

I could probably do this for the high level interactions, for example between entities. I'm not sure I want to include that information in every test but I could use it as a design technique and encode it in a few tests. This is quite high level interactions so I avoid the risk of overspecified software.

Ultimately I would still need some state tests (see this thread for a good discussion of the reason you still need state tests) but I'd be using interaction testing to drive my design.

However as I say I find a domain model is filled with all sorts of little domain classes that only exist because we chose to refactor the code to make it read better, these classes are not necessarily part of the ubiquitous language and are purely an imeplementation detail (they are pure fabrications).

Making interaction testing work for these pure fabrications seems to me to be a bit of a bad idea, these classes exist because of refactoring and I cannot plan for the interactions with them upfront.

Maybe if I stick to only using interaciton testing for the high level interactions, rather than interactions with pure fabrications, I'll get the benefits of interaction testing without the costs. I think thats what I'll try next.

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

Identity In Forums

I'm not overly bothered about the identity issue that was discussed on the ALT.NET forum recently but it did make me think of this DDD thread that I came accross recently. Kinda amusing seeing people seriously respond to someone with a nick like that.

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

Crap4J - Code Complexity and Coverage Analysis

Crap4J was mentioned in the ALT.NET forum, seems like another interesting code analysis idea but this time it does code complexity and add code coverage.

There is also an entertaining video that covers the thinking behind it, and it sounds like Crap4N is on the way too...

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

AOP - Alternatives To PostSharp

Whilst looking at PostSharp I found quite a few useful links and also managed to look at a few alternatives.

Aspect# seemed interesting but it only does virtual members (or interfaces I presume) and its certainly not transparent to the user of the classes as you have to go through an AspectEngine. Anyway no matter how useful it could have been it looks like Aspect# is a dead end and is on the way out.

Other than Aspect# there are a few other choices, Spring.NET has an AOP solution and Eric Bodden has a list of .NET AOP solutions and I'll definitely take a look at some of them, AspectDNG in particular sounds good.

I'll be interested to see if I can find any solution thats as simple as PostSharp Laos or that has such a nice way of supporting compile-time weaving.

Links - PostSharp

1. Using AOP for validation
2. PostSharp AOP reference
3. AOP with PostSharp Part A
4. AOP with PostSharp Part B
5. Bitter Coder
6. DotNetKicks - Not much yet...

Links - AOP

1. Ayende - 7 Approaches To AOP In .NET
2. Characterization Of Current Approaches
3. Spring.NET
4. Eric Boddens List Of Current Approaches
5. Wikipedia

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

AOP and the Domain - Dirty Tracking

A new requirement has come in to our system, essentially we need to be able to tell external systems when (some) changes happen to our domain objects. How we notify the systems is one issue but how we actually track domain changes is another one.

Some of the changes are quite high level, such as a Customer state change, and some are just little changes to the data of an object, such as a change to a Customers first name.

We could handle the high level state changes by calling through Service classes, for example CustomerStateChangeService.Activate(customer). However we also need to think about how to track all the data changes, we've considered a few ways that we could do this and two of the most obvious are:

1. Services - Instead of directly setting a Customers first name call through a Service which would then take care of ensuring that we give other systems a chance to track the change. We could look at something like the anticorruption layer example.
2. Domain Events - The domain classes could raise events, to some extent this is nicely decoupled but it bothers us that our domain objects would be raising events simply because an external system needs to know about the change. It also means that pretty much every property setter in the domain could potentially be raising an event once its set the value, not very elegant.
3. NHibernate - Maybe include an interceptor that can help us work out what has changed when NHibernate comes to persist. This sounds easy but in practice would be a mess and certainly isn't very intuitive.

Anyway these and other solutions didn't appeal so I started looking at PostSharp. Now I'm no fan of overly technical solutions to domain problems. However I'd heard good things about AOP and thought it might help us solve the problem, especially since logging is quite often given as an example of where AOP can help. I was thus hoping that it could give us a good, simple, solution to our problem.

However when I came to use PostSharp I couldn't believe how good it was. In particular it allows you to use attributes to specify code that you want PostSharp to inject in post-build...

Example

To show how simple it is I've tried to come up with what I consider to be a useful example which you can get from google code. In order to run it you first need to install PostSharp, once you've done this you can open and run the project.

First off note that SimpleDomainClass is marked with AllPropertySetsNotificationAttribute. If you open AllPropertySetsNotificationAttribute you can see that it is using reflection to attach an extra attribute, PropertySetNotificationAttribute, to each property setters.

This may seem silly until you run the application and see that the code in PropertySetNotificationAttribute.OnSuccess is being automagically run.

This is happening because the post-build PostSharp process is ensuring that where it sees a method boundary aspect, such as PropertySetNotificationAttribute, it inserts the necessary IL to ensure the code in the attribute is run.

You can see this if you open Reflector and view the disassembly output for SimpleDomainClass, look at the property setters and note the extra code including the call to OnSuccess in the attribute.

In case you were wondering this is a simplified version of the binding sample that actually comes with PostSharp.

Usage

In our case you could easily imagine PropertySetNotificationAttribute calling out to a IDomainChangeNotificationService, the actual implementation could be retrieved from a Service Locator or injected in using IOC.

Project References

You will note that our domain assembly references the assembly that I've put the attributes into and also PostSharp.Laos and PostSharp.Public. This bothers me slightly but from what I can see they are quite lightweight assemblies so it doesn't seem to be a killer.

Conclusion

I'm still at the earlier stages of understanding PostSharp but I'm very impressed.

Like TypeMock and NHibernate it is very powerful and also seems to come with very good documentation.

I'm also stunned by how easy it was to do what I wanted to in this case, but then I guess I shouldnt be as the docs indicate that Laos has been designed to be simple rather than being fully featured.

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

Interfaces and Abstract Classes In The Domain

I was just looking at a DDD example that had an interface on nearly every class in the system, including the domain classes. One reason for this is mocking (which I don't favor for the domain anyway) but the other seemed to be to improve the design. This second reason made me think I should disuss why I don't think the "everything needs an interface" approach is a good one for the domain.

First off I should say that the topic has already been discussed.:

1. DDD Thread
2. Pro Interface View
3. Pro Abstract Class View

I disagree slightly with the two viewpoints, to me you only need abstract classes or interfaces in a minority of cases. In the domain I believe you should only add an abstract class or an interface where you believe that the addition is improving the design, most commonly when it is a useful abstraction.

I do agree with the second view as even when you do have a useful abstraction an interface isn't always enough, you sometimes want to enforce the constraints (bake them in) and an abstract class is better for this.

Having said that I wouldn't take my Customer class and just create an ICustomer interface (or an abstract base class) on it, instead I'd look at the usage of the class and the coupling to it which might lead me to extract meaningful interfaces. In fact in many cases I'll just start out by referring to the concrete Customer domain class, only introducing abstractions where I know they are needed.

In summary only put in interfaces or abstract classes in the domain where they are helping, don't go for what Fowler refers to as "Interface Implementation Pair" approach.

Actually this post sums that up my view nicely.

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

Domain Presentation View

Was just reading a blog entry from Ray Houston on his view classes. The scary thing is we have exactly the same approach, right down to the naming of the classes!

In our case if we had a Customer aggregate and we were displaying lists of Customers in a grid then loading each instance of the aggregate would be deeply inefficient. We'd be loading lots of data/rules that we didn't need and we'd also be missing information that we needed to display in the grid because that information would come from other aggregates. We might thus end up navigating associations from one aggregate to another just to get simple primitive data types to display in the grid, which is wildly inefficient.

What we really needed for these situations were fast loading read-only classes that have information from one or more aggregates but that only load the information/behavior needed for the display in the grid. Enter our Info objects.

We have Info objects (ClientInfo) and InfoLoaders (ClientInfoLoader). The loaders only have retrieval methods and are not repositories. The Info classes are then mapped to database views.

We actually have the Info objects in another assembly called Presentation, but we do have a reference from the Presentation to the domain assembly so that the Presentation classes can use things like Services/Rules/Specifications/Enums and so on. We could remove this dependency if we needed to, but it would be a little bit of effort and so far I don't see it as a major issue.

So far we only have a few Info objects, certainly not one per aggregate. We also don't create one Info object for each view (as in an MVP view) so its possible that when you load an Info object you get data that you don't need. If this became an issue we could deal with it.

Anyway I shouldn't have bothered explaining it as Ray has already done a good job. I also believe there is a discussion of this sort of thing on the DDD newsgroup (don't have link), but it is heartening to know we are not the only people using this approach.

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

Domain Model Project Structure

Myself and two colleagues had a very interesting discussion about the structure of our domain projects. Originally we had this sort of folder structure within our domain projects:

This wasn't awful but it also wasn't perfect, after a bit of work we decided to restructure like this:

Its difficult not to prefer this folder structure as it keeps things that are related together in the folder structure and emphasizes key abstractions/classes (such as Customer here).

Unfortunately we've had to create "Component Parts" folders that, we plan, will contain any classes that are not key aggregate roots. The top level "Component Parts" folder has very reusable classes, but the one within "Customer" is for classes that relate just to the "Customer" aggregate(s).

This idea of a "component part" may seem odd but it does help show that whilst CustomerIdentifier is important it is not in any way as key as Customer.

The discussion also emphasized that it is impossible to get a project structure that we are completely happy with, trying to impose a single hierarchy on a domain model is just so difficult to do cleanly.

Its also worth noting that the small size of this example means it is not a good example, but we have already started giving this folder structure a go and so will hopefully find out just how well it works.

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

Repository Implementation (DDD/NHibernate)

Christian Bauer (Hibernate bod) has written a post about the repository pattern. I think the post is a little bit misinformed and concentrates too much on one possible way to implement the repository pattern, however it does show that people are still having trouble working out how to implement repositories so I thought I would explain how we do it.

I actually think the pattern is relatively simple, especially when used with NHibernate, so here goes...

1. Accessing From The Domain
I don't acces the repositories from the domain, with NHibernate I rarely see the need. I don't actually want to couple them because:

1. Complexity - Having the domain classes call the repositories makes it harder to understand them.
2. Testing - Most DDD practitioners seem to focus on state testing and thats certainly my preference, but if your calling repositories from the domain those tests become (as I see it) layer crossing tests and testing becomes more difficult.

I don't want to have to mock out repositories when testing the domain, for me thats reason enough to avoid the coupling. There isn't too much about this one the Web other than one forum post and bits and pieces on peoples blogs, but making your domain testable in isolation is (in my view) well worth the effort.

2. Associations
I tend to focus on modeling the most important associations in the domain.

Within an aggregate this is simple, you can always navigate from the root to the parts.

Where I want to associate one aggregate with another I'll put the most important association in the domain model and (optionally) handle the inverse using a repository e.g.:

IList orders = customer.Orders;
Customer customer = customerRepository.GetForOrder(customer);

Ofcourse sometimes you might bidirectional association here, if it wasn't costing you too much complexity/coupling wise.

Note that in many cases people focus on modeling the association from the one to the many, e.g. Order to Customer. This sometimes works, sometimes it doesn't...do whatever makes sense. I try to do it without simply putting in the associations that make persistence simplest.

3. Implementation With NHibernate
NHibernate makes cascading and lazy loading simple. In the mapping files I don't lazy load within an aggregate though I do lazy load between aggregates, cascading only goes as far as aggregate boundaries.

The implementation becomes ridiculosly simple, for example for our key repository its basically this:

public class CustomerRepository : Repository
{
//..any custom queries
}

The base class is doing all the heavy lifting, for simple cases all I need to say is that the key to the Customer table is an int (using a generic generic parameter, which is missing from the code because blogger is cutting it out :)).

The base class is also very simple, it has methods for SaveOrUpdate/GetById/GetAll and we have extra an IDeletionRepository that we can add on which just has a Delete method. We also have a RetrievalRepository base class for completely readonly cases.

I am coupling the implementation of my repositories to NHibernate but that has so far not proved to be an issue. What we do strive to avoid is putting anything NHibernate specific on the interface of the repository, not just to follow the pattern but because its sensible as we may not always use NHibernate for all of the queries. So I avoid making the repository a leaky abstraction by, for example, passing in some ICriteria to one of the queries.

3.1 Testing
Testing the basic Save/Update/Concurrency also becomes mickey mouse as we have a base class called AggregateRootPersistenceTestBase that does the heavy lifting.

As an example this base class has a TestSaving method that delegates to a SaveTestHelper, this class does the following:

1) Create Repository - Create an instance of the repository under test.
2) Create Aggregate - Create an instance of the aggregate we are testing the persistence of.
3) Save - Save the aggregate to the database (save then flush).
4) Reload - Evict the saved aggregate from the session (or Clear the session) and reload it from the database. We could instead use a seperate ISession, either way we are ensuring that the reloaded object is fresh from the DB (not from the first level cache).
5) Compare - Compare the two objects, this works as I've written an ObjectHierarchyComparer that can be given two objects and will use reflection over their properties to ensure they match. In navigates right down the hierarchy until it gets to build in primitives to compare so can handle very complex object structures.

This is very simple, all you need to do to use SaveTestHelper is pass in two delegates, one that creates the repository and one that creates the aggregate. You can optionally pass in a string[] of property names that the ObjectHierarchyComparer should ignore (such as properties that get default values from the DB, because the reloaded object will have different values for them).

This is all very reusable. We then write tests for the aggregate roots in a few different scenarios:

1. Unpopulated - Create an instance and save it.
2. Populated - Move it into a non-default state (if it has lifecycle), populate the entire aggregate.
3. FullyPopulated - Same but with associations to other aggregates populated.

We also test other parts of the aggregate, I can provide more details if its useful...

3.2 Custom Queries
Any custom queries are written in the repositories, preferably in HQL/ICriteria so we can refactor the DB or code (made harder if you encode SQL). You could actually put the HQL into a named query in the mapping file if you wanted to.

3.3 Eager Fetching
We haven't really dealt with this issue fully yet but Udi Dahan has posted about it. I don't think I'd use his implementation but I do like the idea of fetching strategies and I'd probably choose the appropriate one in a coordination/application layer.

4. Specifications
We probably underuse specifications, they can be useful if your getting lots of custom queries on the repositories that are all just for specific cases:

public IList GetByFullName(...);
public IList GetByFirstAndSurname(...);
public IList GetBySurname(...);

You could encapsulate these name queries in one or more specifications and pass them in:

public IList GetByName(CustomerNameSpecification specification);

The problem is converting your (domain) CustomerNameSpecification into a query. I don't want the class itself to be talking in terms of SQL/HQL/ICriteria so choices that we've though of are:

1. Conditional - A single CustomerNameSpecification and the CustomerRepository picks it apart, for example the CustomerNameSpecification would have a FirstName property and if its not null the repository adds an appropriate ICriteria to the query.
2. Switch - Subclasses of CustomerNameSpecification (such as CustomerFirstNameSpecification) and a switch in the repository that calls an appropriate method to create the query for each type of specification.
3. Visitor : This one of the GOF patterns. Subclasses of CustomerNameSpecification (such as CustomerFirstNameSpecification) and each "accepts" a QueryVisitor, the power of double dispatch is then used to ensure the appropriate method is called on this class.

None of these options are great, though the third is definitely the least awful.

My hope is that in the future extension methods and LINQ should make this easier.

5. Performance
I've discussed eager queries but sometimes domain clases just aren't appropriate. For example we have cases where we display lists of objects in the GUI, for example we might have a grid displaying Orders that actually displays the Customer name.

Loading each Order domain object and the associated Customer is going to be deeply inefficient, for those cases we map seperate presentation (or as we call them info) objects.

We'd thus map an OrderInfo class to a database view that would bring in the information that is needed from whatever tables are involved. These classes are loaded using Loaders (not repositories) to emphasize that they are not domain classes. We also nly create these classes if we are sure that they are needed, so you only find them where we have proved that using the domain classes was going to cause performance issues.

It is worth emphasizing that this is not a presentation model, these are read-only classes that are not in any way associated to the aggregates in the domain.

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

New Features In NHibernate 2.0

Ayende has just blogged about the new features in NHibernate 2.0, the one that we are most interested in is the ability to map multiple tables to one class. This is very useful and we've been using it for a while.

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

Podcasts

I listen to a few podcasts but my new favorites are:

1. Software engineering radio - The "enterprise" episodes are great, but I'm yet to be sold on the ones that are on other topics (such as real time systems).
2. Ask Udi - Good content but the topics are so interesting that the podcasts seem too short, I'm hoping for an extended version in the future.

I have to say both are very useful.

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

Evolving Coordination Layer

I've posted about this before but on my project we have a coordination layer that sits above the domain but I thought I'd add another post about it.

Since a coordination layer is quite closely linked to a domain assembly we have more than one of them, so if we had two domain models our projects would be:

1. Company.Customers.Domain
2. Company.Customers.Domain.Coordination
3. Company.Customers.Peristence
4. Company.Finance.Domain
5. Company.Finance.Domain.Coordination
6. Company.Finance.Peristence

This gives me a lot of flexibility. For example our Finance domain has a reference to our Customers domain but there is no reference going the other way (at all). This is the way we want it but we have a process where by to create a Customer you must already have a saved CustomerCreditCheckRequest object from the Finance assembly, we put that logic into a CustomerCreationService in the Coordination layer. This service would be very short and its form would be:

1. Create the Customer by calling into a CustomerFactory within the Customer domain assembly.
2. Create a CustomerCreditCheckRequest and associate it with the new Customer before saving it. This logic obviously calls off to a repository and to the Finance domain and so cannot go into Company.Customers.Domain.
3. Return the Customer.

The class names are all made up but you see my point, and note that all the interesting domain domain logic is kept within CustomerFactory. It does mean the coordination layer is quite highly coupled (in this case to Finance) but if that becomes a problem we can deal with it (interfaces and injection), and for now it doesn't seem to me to be at all important.

When Is A Domain Service Enough?

There is another "issue", what do if we already have a coordination layer service and no domain service and want to decide where to put some code. For example lets say Order/Customer aggregates are in a single domain assembly but a rule is that for an Order to become active we must ensure the Customer has a valid Address. This is a cross aggregate rule but we could enforce it in a domain service, there is no specific need for the coordination layer to be involved. So we could have an OrderActivationService in the domain, however we already have an OrderService in the coordination layer...do we put the code in there instead?

Although I originally thought of just putting the cross aggregate logic in the domain I've been swayed by a colleague and of course even we could put a call to the OrderActivationService (domain) inside a suitably named method in the OrderService, keeping the logic in the domain but giving a simple single class interface to the GUI.

Compared To Service Layer

Evan Hoff did point out that this layer could be mistaken for a Service Layer, the links is here. As we discuss they are quite different as the coordination layer is not responsible for things like email/transactions/session management and is very closely linked to the domain itself. Not to say we might not also need a service layer at some stage, or that the coordination layer might not become one in time...

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

xUnit Test Patterns

The first thing you notice with this book is the sheer size of it which is a little daunting. However you quickly realize that you don't actually need to read the entire thing cover to cover, the pattern based layout means that you can leave a lot of the content for use as a reference if you choose to.

Before getting to the patterns the book covers several other topics including test smells and principles, I thought these sections were as important as the patterns themselves so I thought I'd write a short section on each of them.

Test Smells

The smells are put into several categories:

1. Project - These could be around quality/cost/resources and are the sorts of things that a project manager might notice.
2. Behavior - You see these during compiling or running the tests, for example tests that are fragile.
3. Code - Problems with the quality of the test code, such as duplication.

Each section has multiple smells in it and each of the smells is discussed in a good level of detail.

Philosophy
This is covered, superbly, in chapter 4. Meszaros describes the fact that your testing philosophy will affect the way you test and that it is thus important to understand different approaches to testing. In particular he identifies some philosophical differences:

1. Test First or Last :- Whether to do true TDD, test last or something in between.
2. Test or Examples :- Do we view our unit tests primarily as specifications or tests.
3. Test-by-Test or Test All-at-Once :- Do we write a test then the code to fulfull it, work out all the tests for a class before writing the code or do something in between.
4. Outside-In or Inside-Out :-Highest level testing leading inwards to lower level testing or vice versa, can affect the way you test with dependencies.
5. State or Behavior Verification :-The same sort of thing as covered by Martin Fowler in his article Mocks Aren't Stubs. His view is that behavior (mock/interaction) testing can lead to tests that do a better job of isolating the system under test (SUT) but at the cost of more difficult refactoring.
6. Fixture Design Upfront or Test-by-Test :- How to handle your test fixtures, an important topic covered in superb detail in the book.

Meszaros then lists his personal philosophy:

1. Test first
2. Tests are examples
3. Write the tests one at a time, sometimes listing all the tests to help his thinking.
4. Outside in development helps clarify the tests to write at each level.
5. State verification is his preferred option, going for behavior (interaction or mocking based testing) verification where he needs to in order to increase coverage.
6. Performs fixture design on a test-by-test basis.

I personally found this chapter of the book excellent and it led nicely onto the section on principles.

Principles

Meszaros uses the term principles because they are not things that everyone will agree with and are too high level to be patterns, the list is discussed at this link but I've chosen to list the first three here:

1. Write the Tests First
2. Design For Testability :- Decouple ya hear.
3. Use the Front Door First :- Overuse of backdoor verification or behavior verification and mocking can result in overspecified software (fragile tests). The author recommends using behavior verification where appropriate, such as when doing layer crossing test.

Patterns

Subsequent sections cover test smells and patterns in more detail. I would say that some of the test patterns are less useful than others, but in general these sections are very comprehensive and will be useful whehter you choose to read them in detail or just use them as a reference.

How It Ties Together

What I love about this is that as you get to this chapter you begin to see how things tie together.

For example if your philosophy leads you to prefer state based verification (as the author does) then the principle of using the front door first makes sense to you.

This decision is then backed up by the later section on Interaction Styles and Testability Patterns which discusses why and when round-trip tests are preferrable to layer-crossing tests (not violating encapsulation being one advantage with the fact that you don't get overspecified software being another).

In turn you may then get smell of Behavior Sensitivity which can lead you to need to use the patterns Creation Method and Custom Assertions.

It is truly superb, you can really go from one section to another and see how it all ties together which is all important as if we don't really understand why we do what we do and what the alternatives are then we can't possibly choose the best path.

Even better the author forces you to see that there are multiple ways to test and each is valid, reminding you that you must be open minded about other peoples approaches.

Summary
This really is an excellent book, I'm not alone in thinking this either and Sam Gentile has posted about the book in the past and the reviews on Amazon are excellent.

I think I've learnt a lot from the book, its made me question some things and confirmed some of the ways we test. For example we currently use state based testing of our domain using the front door, which the author confirms is his preferred approach (its also the approach most DDD practitioners go for). However when someone joined our team recently she pointed out that our testing of our coordination layer could be improved if we focussed more on interation testing, especially as they are usually layer crossing tests.

If I have one issue with the book its that in some places it doesn't link togther too well. For example smells/principles/philosophies/patterns are linked and sometimes the relationships are not made clearly enough. A table linking a philosophy to principles then patterns and strategies might be worth trying coming up with...

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