The problem is that programs are complicated. I don’t tend to help the issue. In a flash I don’t hesitate to layer on additional complexity with domain models, frameworks, and complex infrastructures. Entities, sevices, repositories and aggregate roots – they’re the tools that we reach for all too often. That is not to say that Domain Driven Design is a poor paradigm – I’m a big fan – it’s just not always necessary.

Take for example a typical scenario. You are given an integer which uniquely identifies a customer and are asked to generate a report of all their orders, export it to a pdf file and return as a Stream. My first impulse is to start with the customer and order objects, identify the bounded context, figure out the aggregate roots, start writing data access mapping code, and so on. If I’m lucky, I only do this for a few hours before hearing the voice of an incorporeal Ted Neward yelling at me to STOP. I was not asked to build a domain model, I do not need to keep track of state, there is no validation, or (much) business logic. The problems that DDD is intended to solve are simply not present here. I need to do one thing and one thing only, map an integer to a Stream!

And yes, I do realize that this is exactly what the CQRS guys have been harping on for years.

My Solution:

Each of my last few projects has contained a very simple interface.

public IMapper<INPUT_TYPE, OUTPUT_TYPE> {
  OUTPUT_TYPE Map(INPUT_TYPE obj);
}

Get it? Put in an integer, get back a Stream, what could be simpler? Ok, maybe that’s too simple. Any change at all would require modifying the implementation. This is all that icky procedural programming stuff. What about reusability, encapsulation, separation of concerns, and our other OO goodies? Fortunately, we don’t have to give these up. All we have to do is introduce a couple of obvious seams. We no longer transform an integer directly to a Stream. Instead we:

1. Take the id and map it to a DataSet that contains the report data.
2. Map a DataSet to the appropriate fully built Crystal Reports ReportDocument.
3. Map a ReportDocument to a MemoryStream of a pdf file.

IMapper<int, DataSet> _dataProvider;
IMapper<DataSet, ReportDocument> _reportGenerator;
IMapper<ReportDocument, Stream> _pdfReportExporter;

public Stream GetCustomerReport(int customerId) {
  return _pdfReportExporter.Map(
           _reportGenerator.Map(
             _dataProvider.Map(customerId)));
}

Pretty nice huh? Well not that nice. If you’re a naming perfectionist like I this should make you shiver. When it comes to maintainability, good intention-revealing namespace, class, and method names are worth a million unit tests and n-tier architectures. Forget requirements docs and self-documenting code, proper naming is the number one tool for communicating our intent.

I lecture my team on this constantly and yet I allow myself the use of the the term “Map”?! A generic term that could indicate anything except (unless you’re a cartographer) a concept from your ubiquitous langauge. I should be ashamed.

We want to keep our generic IMapper interface though, it’s so slick, allows us to write minimal code and you you could easily imagine it coming in handy. For example, perhaps as the domain itself becomes more complicated, it becomes useful to break our IMapper<int, DataSet> down further.
1. The integer is get mapped to a Customer entity.
2. This gets mapped to a ReportSpecification.
3. The ReportSpecification is evaluated and mapped to a StoredProcedureInvocation
4. The procedure is executed and finally returns our DataSet.

You could imagine all sorts of neat little tricks you could play with our IoC container – we could have it automatically link transforms together or subsitute out implemenations. Simply by knowing that all these components transform one object to another we could configure automatic caching, deferred execution proxies, and so on. All things that are made far easier because all transformations are achieved via IMapper.Map.

What we really need is a way to introduce aliases for the Map() method. Preferably ones that depend on the input and output type. So why sit there scratching our heads? C# is a flexible enough language, let’s just let’s do that thing that I just said.

public CustomerOrderReportGenerator : IMapper<DataSet, ReportDocument> {
  public ReportDocument Map(DataSet data) {
    // implementation
  }
}
public partial static class AliasExtensions {
  public static ReportDocument GenerateReportFrom(this IMapper<ReportDocument, DataSet> mapper, DataSet ds) {
    return mapper.Map(ds); }
}

And now we have aliases:

  _pdfReportExporter.Export(
    _reportGenerator.GenerateReportFrom(
      _dataProvider.GetOrderDataFor(customerId)));

The poor readability of this bothers me. The LISPers among us might not mind reading backwards through a stack of nested parentheses but as a fan of fluent interfaces I’d like to see my code read as close to natural english as possible.

Same trick, now featuring double dispatch!

public partial static class AliasExtensions {
  public static ReportDocument ComposeIntoReportUsing(this DataSet ds, IMapper<ReportDocument, DataSet> mapper) {
    return mapper.Map(ds); }
}

Allows us to do:

  return _dataProvider
    .GetOrderDataFor(customerId)
    .ComposeIntoReportUsing(_reportGenerator)
    .ToStreamUsing(_pdfReportExporter);

And there you have it. Nice, fluent, and composable.

What do you guys think? Aliased Maps a good name?

… unit tests … verify that the business logic is correct.  I believe that for it to be unit testing it has to use a testing framework like nunit or junit.

I say thar be dragons!  Tying your understanding of unit testing to a specific tool allows you to neatly sidestep thinking about what  testing actually does.  Additionally, you deny credit to an excellent tool like NUnit by pigeonholing its purpose.

Consider for a minute what NUnit actually is.  Yes their own website claims that they are specifically a “unit testing framework for all” but what does it actually do?  In my opinion it is a framework for setting up an application’s state, executing code, and then asserting that the resulting state is as you expected. That’s pretty broad.  Way broader than the confines of mere unit testing.  

Take the excellent WatiN or (no longer maintained) NUnitASP tools.  Both can be run using NUnit but neither is used to build a true unit test.  WatiN for example remote controls your browser to investigate how your page will react to certain stiumuli.  What unit does WatiN test?  Your Page_Load method?  Your page renderer?  Whether the viewstate persists that you had entered some text halfway up the page before submitting and the text is not cleared when your page returns with a validation error?  The localhost routing mechanism on your PC?  Or does it test the integration of all of these?

I made the same exact mistake myself when I decided to ’see what this TDD thing’ is all about last April.  I ultimately had to delete my entire testing project after I came to the realization that each test bit off far too large a chunk making it utterly impossible to maintain once true refactoring started.  I nearly cried that day.

But out of the ashes I was reborn with what I hope (but don’t really expect) to be the final zen-like understanding of this unit testing thing.  The first aha moment was when I finally caved in and decided to learn Rhino Mocks and my understanding sharpened when I caved again and looked into the new Rhino Mocks 3.5 AAA syntax.  Overall the lesson seems to be that I’m always wrong and I will eventually give in on everything and like it.  My girlfriend will be happy to hear that.

Let me tell you how I understand unit testing now.  Imagine a room.  You are standing on the outside and can comunicate with its ouccupants through a two way loudspeaker.  This room is your unit – if it helps you can imagine the room as painted black.  Now in testing you present your unit with a problem:

Given that you are on 735 Bourbon St New Orleans, Louisiana how far is it to my grandmother’s house?

I used to think that unit testing involved merely waiting for the answer:

Your grandmother’s house is 1345 miles away and you haven’t visited in months you shmuck.

Now I realize its more about everything else that is said.  “Where does your grandmother live?” and “Can you be so kind as to  slip an atlas under the door?” should definitely be questions that you hear over that loudspeaker.  If you’ve separated your resposibilities properly the unit will also require a calculator that given two points on a map can tell you the distance (the specific calculator implementation should depend on whether you intend to fly or use the highway system).  The unit might even request that you hang a EnRouteToGrandmas = true sign on the door.  

The point is that you’re not so concerned with the final answer as much as you are with the unit asking the right questions.  Afterall, without that information know that it could not possibly be doing what you mean for it to do!

And so I define unit testing as

Verifying that given an input, a piece of code makes all the external requests that you would expect where the unit is small enough that the number of these can be enumerated with ease.

Note that this definition does not necessitate automated testing and this is something that I again think is basically correct.  After all, a framework should not do anything that you cannot do for yourself.

The beautiful part is if you’re limiting the amount of requests that you’re going to expect – let’s say no more than four – single responsibility emerges almost all on its own.  After all, how much can a piece of code do if its not communicating with the external world?

So there you go, thats my understanding of unit testing.  I look forward to being proven wrong in the future and having to refactor everything all over again.  But until that time,  Zachariah, you’ve been blogo-served!

Disclaimer:  I do not know Zachariah personally but he seems like a smart guy that is highly involved in the ALT.Net community.  I do not purport to be more knowledgeable than him in programming issues, I just disagree with him on this one point.

Technologies that I HAVE to learn:

• NHibernate – The alt.net list, podcasts, and .NET blogs have been a buzz about this for so long that its barely even mentioned anymore, but yes, through argument and experience I’ve been convinced, dynamically generated SQL is the way to go.  Time to get a crackin’.
• MbUnit – Apparently that’s what a lot of the pros use and I want to  be a pro right?  Well, I’ve got the basic [TestFixture] – [Test] – [RowTest] stuff down but guys like Phil Haack have to love it for more than just a few neat features and a nice GUI right?  How about reading the documentation?  Also, what the fuck is Gallilo and how come I can’t get it to run?
• StructureMap or Castle Project – Inversion of Control / Dependency injection frameworks.  This is what you use if you want an extensible application.  And I do.
• F# – A couple months ago, I realized that I kinda like programming in Javascript. Apparently, I’m not the only person that thinks so.. I guess it was because I was finally starting to get an understanding of what this functional programming thing is all about. And now that that I know, I like it!
• And in a similar vein – JQuery. – Yeah, I’ve gotten some practice with this amazing toolbox in working with my personal site and The Roots Of Music and I think there’s something there. I want more, a lot more.
• Git or Mercurial – Distributed Version Control Systems.  These seem to be the new thing in version control, no pressing need to switch from SVN, but I should start getting familiar with them.  It seems like for the time being, Mercurial is the shiznit.  Not sure if any of them have nice TortoiseSVN-style support though.
• TypeMock – Commercial mocking software.  Type mocking is really just something that I need to learn about as I’ve run into the limits of non-mocking unit tests already.  I’ve heard this product is good in a few places and they have a good learning section the web-site as well as a free download version.  Could be worth trying it out.  As an alternative, we’ve also got Rhino Mocks which is free.