Category Archives: patterns

Functional-style programming – Easy debugging!

Ever since LINQ arrived in C# land, a lot of people have been using a functional style of programming without even perhaps being conscious of it. 

I always chuckle when I read the words “functional style”, because I picture grim marches across a barren landscape, brutalist architecture and people with beards. 

One particular facet of programming in a functional style is where, rather than mutating an existing piece of data, input data is transformed / projected into something new via a pure function.  Since this style of programming limits the number of side-effects, it makes debugging a comparatively wonderful experience. 

Read more »

Multiple Mocks?

This post was in response to a post on the blog (the comments aren’t working for me, so I thought I’d post it here) which I read via Roy Osherove.

Basically, the author was querying Roy Osherove’s rule of thumb that stated, “more than one mock per test is harmful”.

He then goes on to provide an example where one action has two identifiable/observable results, and two mocks are used.

Figure 53b: Two Mocks (I’m so, so, sorry)


Read more »

Data oriented design links

I’ve been doing a little reading around data oriented design of late and thought it was worth sharing some interesting links. Here’s my distillation of the reading I’ve done so far (caveat: I may be talking balls).

Prelude: Battling Dogma

All too often, games programmers butt up against dogmatic catch-all declarations of “virtual functions are slow!”  For the general case, this can be proved as a nonsense as virtual function calls are blatantly not slow!  They’re very, very fast.  However, if someone said instead, “virtual functions are slow when iterating over large collections of heterogeneous types because of cache misses” then that’s another matter, entirely.  Unfortunately, we all too often hear the former declaration rather than the latter.  It’s neither compelling (as we can prove it is incorrect in the general case) nor edifying.  Most programmers like to learn things, so it’s nice to read some illuminating articles about a touchy subject.

The gist of it

Data oriented design is based on examining the access patterns and transformations performed on data.  The code is then structured to make it data-centric by using a combination of changes to the type of data stored, the way it’s laid out in memory and the ordering of the data, amongst other things.  An instructive example of this is given in the BitSquid article where animation data is ordered by time, as this best fits the common access pattern that a game would use.  Another particularly useful example is where data structures are broken up into multiple parts so that more of the data used by common operations fits into the cache.

The main benefit is reducing cache misses, but a nice side effect is the increased opportunities for parallelisation.  A lot of this stuff is well-known and as old as the hills, but in my experience it’s often been bundled with dubious practices, so it’s nice to see some practical, tangible examples of when and why you should apply such techniques.


Games from Within Article — A high level article; Noel works through some disadvantages of object oriented design and then cites some examples where data oriented design can be employed to speed things up.

Pitfalls of Object Oriented Programming — Tony Albrecht of Sony has some very interesting diagrams, slides, timings and statistics that lay out the costs of cache misses and branch prediction failures with very specific examples, then optimises via various means.

Practical Examples in Data Oriented Design — Bitsquid engine programmers dish out some examples of designing with data access in mind.  Higher level that the Sony presentation, but also very useful.

GameDev discussion thread — Generally useful discussion thread.  Has some code examples, too.

Typical C++ Bullshit — Code annotated by cranky post-it notes.  Not exactly an illuminating discussion or an article as such, but worth including for completeness.


Game Entity Systems — The T=Machine blog has a series of posts on designing game entity systems.  One part of the series deals with processing homogeneous data and why this makes it fast / more easily parallelisable.

Castle DynamicProxy2 quirks

I’ve been faffing around with Castle.DynamicProxy2 a bit lately and it’s a pretty interesting bit of kit.  Castle Dynamic Proxy (CDP) allows you to dynamically generate proxies at runtime to weave aspects of behaviour into existing types.  Aspect oriented programming is typically employed for implementing crosscutting concerns such as logging, performance measuring, raising INotifyPropertyChanged and various other types of repetitive and/or orthogonal concerns.  I’m a newbie to this stuff so I won’t say much more on AOP.

While I really like CDP, I’ve found that the documentation and tutorials (the best of which is Krzysztof Koźmic‘s excellent tutorial series) aren’t particularly explicit on how CDP achieves its effects, and sometimes these details are important.

There are two main ways of creating proxies that most developers will encounter.


This is nearly always the first demonstrated method in tutorials.  ProxyGenerator.CreateClassProxy dynamically subclasses the target class, so if you have a class named Pogo and you call ProxyGenerator.CreateClassProxy, what you’ll get back is an instance of a subclass of Pogo (i.e. the new type is-a Pogo) that weaves in the interception behaviour via overriding methods.  This is why it is a stipulation that methods / properties must be virtual when they’re intercepted.

With class based interceptors, you cannot intercept non virtual methods because unlike Java, C# does not make methods virtual by default.  If you try to intercept a non-virtual method, nothing will happen, though mechanisms do exist to allow you to identify these situations and warn the developer (the most common example of this is that NHibernate will die on its arse if you try to use lazy loading with a non-virtual member).


The second method is ProxyGenerator.CreateInterfaceProxyWithTarget, and it is the primary reason for writing this blog post!  CreateInterfaceProxyWithTarget does not dynamically subclass target types, it simply creates a dynamically generated class, implements the same target interface and then passes through to it.  I.e. it’s an implementation of the decorator pattern.  This has two effects, one of which is very important!

  1. You don’t need to mark your methods/properties as virtual
  2. Since it is a proxy working via decoration rather than subclassing, for the effects of the interceptor to be applied, all calls must be made on the proxy instance.  Think about it.

The most salient point is #2.  I’ll elaborate.

A worked example: Rocky Balboa

Say you have an interface called IBoxer like this:

… and you implement it like this:

If you then turn to aspect oriented programming and decide to gather statistics on punches thrown for the duration of a boxing round, it’s a reasonable assumption that you can simply proxy the IBoxer interface and intercept only the StraightLeft/StraightRight punch calls, tally them up and report the metrics (ignore whether this is a good idea to be doing this, it’s a contrived example).  On the face of it this isn’t a horrible idea.  However, it won’t work as expected.

The key here is that OneTwo() calls through to StraightLeft() and StraightRight().  Once the proxy has delegated to the decorated type it loses the ability to intercept the calls.  We can follow the call graph easily enough.  We have a reference to the proxy via the IBoxer interface.   We call “OneTwo()” on it and when the invocation proceeds, it delegates to the decorated Rocky instance.  The Rocky instance then calls StraightLeft(), StraightRight().  Both of these calls will immediately go straight to the ‘real’ implementation, bypassing the proxy.

Just as with the normal decorator pattern, the decorator (the IBoxer dynamic proxy in this case) loses its influence when the decorated object calls methods declared in its own public interface.  In this particular situation we could write an interceptor that knows to add two punches when OneTwo() is called on the proxy, but compare this approach to one using class based proxy.  If we were using a class proxy we could rest safe in the knowledge that all calls to StraightLeft() and StraightRight() will always be intercepted, as the extra stuff we’ve bolted on resides in a method override.

The results vary depending on the type of proxy we generate and the way the types are written. In hindsight it’s pretty obvious, but it still caught me out.

Data-driven testing tricks

It’s a fairly common occurrence — somebody wants to use NUnit’s data driven testing, but they want to vary either the action under test, or the expectation.  I.e. they’re not parametrising simple data, they’re parametrising the actions.

You cannot encode these things via normal data-driven testing (short of doing really nasty things like passing string names of methods to be invoked or using enums and a dictionary of methods) and even if you use a hackish workaround, it’s unlikely to be flexible or terse.

Test readability is paramount, so if you have some tests written in an unfamiliar style, it is very important to express the intent clearly, too.

NUnit’s data-driven testing

NUnit uses a few mechanisms to parametrise tests.  Firstly, for simple test cases, it offers the [TestCase] attribute which takes a params object[] array in its constructor.  Each argument passed to the TestCaseAttribute’s constructor is stored, ready for retrieval by the framework.  NUnit does the heavy lifting for us and casts/converts each argument to the test method’s parameter types.  Here’s an example where three ints are passed, then correctly mapped to a test method:

The main limitation here is that we can only store intrinsic types.  Strings, ints, shorts, bools etc.  We can’t new up classes or structs because .NET doesn’t allow it.  How the devil do we do something more complicated?

Passing more complicated types

It would appear we’re screwed, but fortunately, we can use the [TestCaseSource] attribute.  There are numerous options for yielding the data, and one of them is to define an IEnumerable<TestCaseData> as a public method of your test class (it works if it’s private, but since it’s accessed via reflection it’s a good idea to keep it public so that ReSharper or other tools do not flag it as unused).  You can then fill up and yield individual TestCaseData instances in the same fashion as before.  Once again, NUnit does the mapping and the heavy lifting for us.

If you do not require any of the fancy SetDescription, ExpectedException etc. stuff associated with the TestCaseData type, you can skip one piece of ceremony by simply yielding your own arbitrary type instead (i.e. change the IEnumerable<TestCaseData> to IEnumerable<MyType> and then simply yield return new MyType()).

Passing a delegate as a parameter (simple)

The simplest case is that you want to vary which methods are called.  For example, if you have multiple types implementing the same interface or multiple static methods, encoding which method to call is very simple.

Here’s an example from Stackoverflow that I answered recently where the author wanted to call one of three different static methods, each with the same signature and asserts.  The solution was to examine the method signature of the call and then use the appropriate Func<> type (Funcs and Actions are convenience delegates provided by the .NET framework).  It was then easy to parametrise the test by passing in a delegates targeting the appropriate methods.

More advanced applications

Beyond calling simple, stateless methods via delegates or passing non-intrinsic types, you can do a lot of creative and cool stuff.  For example, you could new up an instance of a type T in the test body and pass in an Action<T> to call.  The test body would create an instance of type T, then apply the action to it.  You can even go as far as expressing Act/Assert pairs via a combination of Actions and mocking frameworks.  E.g. you could say “when I call method X on the controller, I expect method Y on the model to be called”, and so forth.

The caveat is that as you do use more and more ‘creative’ types of data-driven testing, it gets less and less readable for other programmers.  Always keep checking what you’re doing and determine whether there is a better way to implement the type of testing you’re doing.  It’s easy to get carried away when applying new techniques, but it’s often the case that a more verbose but familiar pattern is a better choice.

AutoMapper and Test Data Builders

I’ve recently been tinkering with WCF and, as many people already know, writing data transfer objects is a pain in the balls.  Nobody likes writing repetitive, duplicate and tedious code, so I was delighted when I read about AutoMapper.  It works really nicely;  with convention over configuration, you can bang out the entity => data transfer code in no time, the conversions are less error prone, the tests stay in sync and you’re left to concentrate on more important things.

Anyway, I immediately realised that I’ve used the same pattern in testing — with property initializers & test data builders.  I’ve posted before about Test Data Builders and I’d recommend you read that post first.

For small test data builder classes, it’s really not that big a deal.  For larger classes, using AutoMapper is quite useful.  For example, for testing purposes we’ve got an exception details class that is sent over to an exception logging service.

Every time the app dies, we create an exception data transfer object, fill it out and then send it over the wire.  When unit testing the service, I use a Test Data Builder to create the exception report so that I can vary its properties easily.  Guess what?  The test data builder’s properties map 1:1 with the exception report — hmm!

So, rather than create the same boilerplate code to map the 10+ properties on the exception builder => data transfer object, I just used AutoMapper to handle the mapping for me :)

I’ve had good results with this approach.  The only bit I’m remotely concerned about is creating the mapping in the static constructor.  Any AutoMapper gurus out there who can say whether there’s any reason I shouldn’t do that?

Avoiding the file system

Going from experience and, as illustrated by Misko’s recent presentation, the more dependencies you have on your environment, the less trustworthy and maintainable your tests become.  One of the foremost offenders in this area is touching the file system.

Any time someone says “hey, I’m trying to open a file in a unit test…”, my first reaction is to say “woah”, and not in the “I know Kung Fu” way!  If you introduce a dependency on the file system, bad things are more likely to happen.  You now depend on something that may not be there/accessible/consistent etc.  Ever written a test that tried to access a common file, or read a file that something else may write to?  It’s horrible.

It is for these reasons that many folk will say “it’s not a unit test if it hits the file system”.  In particular, if you have a TestFixtureSetUp/TearDown method that deletes a file, it’s a sure sign that the fixture is going to flake out at some point.

A real example

Recently at work, my colleagues have experienced the joy of a huge refactoring job pertaining to restructuring our projects/solutions to reduce build times and increase productivity.  This work included maintaining something close to ten thousand tests.

As the job progressed, they kept finding that some test fixtures did not live in isolation.  The tests depended on various things they shouldn’t have and, most saliently, file dependencies proved to be a total pain in the balls.  Everything built OK, but when run, the tests failed due to missing files.  Paths and file attributes had to be checked (Copy if newer, etc.), lost files had to be hunted down and so forth.  It’s hassle that people don’t need!  As I’ve stated before, when it comes to testing, maintenance is king.

Anyway, if you have a hard dependency on the file system, consider the alternatives.  This is never a hard rule as it is not suitable for all uses, but it always worth thinking about.

Alternative approaches

Firstly, abstract the file operations to some degree.  You can do numerous things here, from changing the internal loading strategy (via Dependency Injection) to — even better — separating the loading/use of the file so that the consumer of the file’s contents doesn’t even have to care about the loading strategy.

Once you’ve done this, you no longer need to use files in your unit tests, as you can use plain ‘ol strings, streams or even just directly construct instances to represent the contents of the file.

Say we had a simple class called “MyDocument”, and MyDocument could be loaded from a .doc file on disk.  The simplest approach would be to do something like this:

Approach One

Depending on your needs and the demands of the user, this may be OK.  However, to test MyDocument’s methods/properties properly, we need access to the file system to instantiate it.  If our tests are to be robust & fast, we need something better.  Here’s something that’s testable:

Approach Two

From a testability standpoint, this is slightly better, as we can now feed in an IDocumentLoader instance which the MyDocument constructor uses to get the data.

On the flipside, the MyDocument type now needs to know about IDocumentLoader.  To load a document, the user now needs to know about creating an IDocumentLoader and feeding it into the constructor — it’s more complicated.  I often see people do this as the default step for abstracting their file operations — they alter the code to make it testable, but fail to spot the problems it brings if done at the wrong ‘level’.  If you gnash your teeth every time you have to use your own code, it’s a warning sign that something is wrong.

When we think about it though, why should MyDocument need to know about loading strategies?  In many cases, we can parse a file and produce some output using a factory or builder instead.  E.g.:

Approach Three

To clarify how this works: The DocumentLoader would parse the .doc file and construct the object instances required to build up a real document, then pass them into the document’s constructor (or build up the document via some other means, such as iteratively calling methods on a blank document to fill it up as new items are found — whatever makes sense).  This totally decouples the loading and instantiation, meaning we can test each step in isolation.

I.e. the flow goes: Read Input => Parse Input => Create Document from Parsed Input

Life after the File System

Once you’re no longer dependent on the file system, you are free to use one of many strategies for loading/creating your type.  Depending on the abstraction, some options include:

  • Just declare your data inline in the test methods as a const string, or as a const/readonly field of the test fixture.  This works well for small amounts of text.
  • Add your test files as text file resources.  You can then access the file contents as a static string property.  This is handy, as you get a strongly typed resource name and don’t need to mess around with paths + copying files.  This works well for larger sets of data, or data you want to re-use in multiple tests.
  • Use embedded resources & GetManifestResourceStream.  This is slightly messier; it doesn’t require copying files, but it does require that the namespace + filenames used to reference the embedded resources are correct (runtime failures ahoy).  You also need to handle streams when using this method.

If my loading logic deals with strings, I tend to just build an ‘inner’ parser that works with the strings, then wrap it in another class that opens and reads files, then passes the (raw) string to the ‘inner’ parser class.  This allows me to thoroughly test the parsing logic independent of the file system, but also means I can re-use it for test classes or other cases.  I.e. I can exercise more of the production code without any of the file system pain :)

Depending on the thing being loaded, this isn’t always the best solution, but for relatively simple loading I tend to favour this method.

Benefits of designing for testability

When I started my job as a Software Test Engineer, I had very little knowledge about unit testing.  I had a good degree award and a load of acronyms to put on my (in retrospect, rather horrible) CV.  I thought I knew a bit about design, encapsulation, patterns, object-oriented programming and all the rest.  With a little trepidation, I felt I was ready to face the world as a programmer.

I applied for a few programming jobs at Realtime Worlds and did not succeed.  After the first rejection, I did not become disheartened.  I did what any sensible young chap would do — I went back to the drawing board.  I continually improved my skill, learned c#, created some new programs and re-wrote old programs with the knowledge I’d gleaned.  Every so often I’d check the website or speak to my friends who worked there, asking if anything suitable was potentially coming up.  Eventually, I landed at Realtime Worlds as a Software Test Engineer.

In an ideal world, I would’ve succeeded first time.  After all, it was my goal to be a software engineer.

Picture the scene

My tremendously awesome CV plopped onto the doormat, awaiting the arrival of the hiring manager.  At 9am on the dot, that fine fellow picked it up and was instantly startled.  “Oh my!”, he cried, “Who is this remarkable young gentleman programmer who wishes to join our fine establishment?”

The hiring manager sprinted up the stairs, burst into a CV triage meeting — cheeks purple and lungs wheezing — before hurling my golden-tinted paper across the room.   “Look! Look!  We’ve found him“, he honked.  The lead programmers threw their hats in the air, linked arms and then danced a merry dance.

The search was over, and the party went on long into the night (though the party did involve programming a Spectrum emulator for the 3DO).

It would’ve been great.  Well, in many ways yes.  In other ways, no.  Hindsight being 20/20, I am actually grateful that I didn’t get my first job doing normal development.  Why?

Things wot I knew

Firstly, bear in mind the fact that I said I thought I knew about design, encapsulation, this that and the other.  I did know a little bit, but I knew precisely nothing in the grand scheme of things.  Here’s the lowdown:

My knowledge of patterns was the singleton and some others.  I did know some others, but it may as well have just been “singleton”.  Lalala, I can’t hear you.  I remember the shock when my friend linked my to the “Singleton considered stupid” article prior to getting a job.  “But they’re my best mates!”, I gasped.  “Yeah, but they’re stupid”, he replied, before jabbing me in the eye with a stick and berating me for my incompetence.

My idea of simplifying problems by breaking them into smaller systems usually involved multiple managers all interacting via singletons.

My idea of extensible software was using horribly complicated, deep inheritance hierarchies everywhere.  Yeah let’s make this base class and then…

Pretty much everything I wrote was tightly coupled.  I thought that I had abstracted things away, but in general I just moved problems around.  Nearly every class relied on multiple custom, concrete types.  I never used factories.

I relied on implementation details.  I often reached into classes several levels deep.  House->GetKitchen()->GetSink()->GetTap();  I didn’t just break the Law of Demeter, I dropped it on the ground and used its smashed remains as a (crap) bouncy castle.

I could go on.  In short, as a dumb graduate, I was interested in my craft and enjoyed programming, but I had some bad habits and didn’t understand why a lot of the things I was doing were flat-out wrong, unmaintanable and are diametrically opposed to the principle of least surprise.  However, sometimes you don’t find out about these things until you’re forced to broach a particular topic.

The reason I’m so glad to be a software test engineer is that all, and I mean all, of these coding horrors were laid bare when I started learning how to test properly.  When your code is fundamentally untestable, there is no denying it.

Sowing the seeds

As a newbie, I was tasked with writing tests for a lot of our existing codebase.  This meant I was exposed to a lot of different structures and idioms of production code written by everyone. Some of it was very easy to test; other parts not so much.

We’re a games company and unit testing is not something that has gained widespread acceptance in games.  Back then, it was no surprise that the results were variable.  I spent months writing loads of tests and it took me a long time to feel like I was doing it in a way that I was happy with.

Anyway, rewind back to when I sucked more than I suck now.  Even though I had no idea about what testability concerns should be, I quickly learned through doing.  I read articles and kept attempting to write better tests.

After a couple of weeks, I started rocking back and forth if I saw a static class.  “Oh God”, I’d cry, “What do I need to initialise then tear down this time?”

After a month, I hated the sight of any class containing scores of methods, lengthy method bodies, multiple indentations of control flow logic etc.  “Jeez, what do I need to do to hit this side of the double nested if statement that’s part of a switch which is called in a chain of 8 private methods?  If only the logic were split up into nicer chunks…”

After another month, I started to wonder why many of the tests I was writing were so slow, given that I was only interested in testing one class at a time.  “Oh man!”, I’d exclaim.  “Why do I have to create all these slow thing?  Bah, I can’t even get at the logic I want to test! If only I could instantiate only what I need and totally control the test environment…”

After another month, I reasoned that if an interface were to be provided and the dependencies could be abstracted away into ‘seams’, it made the code infinitely more testable.  “Hmm, I see why loose coupling is good…”

After another month, I wondered why some of the tests were so fragile.  When some system or other changed, the tests for an unrelated class would fail!  “Oh… that’s why singletons are frowned upon.  The dependencies are hidden!”

After another month, a workmate found Misko Hevery’s guide to testability and the penny dropped.  Like Google’s testing blog logo — it was like switching on a light bulb!

Beyond that day, I’ve kept learning more and more techniques to use as part of my development and testing arsenal.  Making my code more testable was the goal, but it has given me so much more.  Testability is a great thing, but as with all software engineering techniques, it is not a silver bullet.

The most important thing is that, with seemingly no concerted (separate) effort on my own part, the code I write to be testable is magically a lot better than the way I used to write it.

Inadvertent Benefits

As Luke Halliwell succinctly pointed out a while back, testability concerns and good design practices tend to converge.  If your code is testable, there’s a greater chance that the problem has been broken down into units of work.  Read his summary; it definitely coincides with my own experiences thus far.

Actively seeking out solutions to make code more testable as resulted in some extremely valuable lessons — it has exposed me to new techniques (such as Dependency Injection) and ways of thinking.   These didn’t just alter the way I tested, they fundamentally altered the way I approach the writing of software.  In the ~x or so years I’ve been programming, designing for testability has been my single most valuable expedition!

Am I suddenly the world’s greatest programmer?  Far from it.  I know scores of folk at work who can program circles around me.  On the other hand, is my code easier to understand, more maintainable, more cohesive and less tightly coupled compared to what I was writing a year or so ago?  Undoubtedly.  Are there fewer surprises?  You bet. Would anyone who had to maintain my code be inclined to hunt me down and murder me?  No.  They may perform some sort of grievous wounding, but I will live.

I can’t believe how much I sucked.  I definitely suck less this year, though.

The Test Data Builder pattern with C# 3.0


Since writing this, I’ve come to prefer the original  method chaining style.  While the property initialiser style works very well for simple builders, the original method chaining style works a bit better if you have nested builders.  See the link in this post for the original; it’s more versatile.

The problem

If you write automated tests, then you are bound to have come across a situation where, during the course of testing your classes, you have to configure them in different ways.  This difference may be slight (say, varying one argument passed into a constructor every time), but it is enough to make instantiating the objects a pain.  You can’t use a common setup method to make life easier, so that leaves you with two obvious options:

  1. Instantiate the objects via a direct constructor call
  2. Abstract the creation a little and use multiple factory methods


The first option is verbose, cumbersome and brittle.  Every time the constructor changes or its rules change (e.g. “parameter string houseName must not contain spaces”), you’ll need to update the tests to use the new form.  If you have scores of calls, writing and maintaining the tests can consume a lot of time, plus it’s tedious.

The second option may seem appealing, but it also has shortcomings.  This is the so called “Object Mother” pattern.  You basically have some factory methods (or a test class) that returns objects in various configurations.  When you have method names like “CreateHouseWithKitchenSinkAndStairs”, “CreateHouseWIthKitchenSinkAndRoof” and “Create HouseWithRoof” (or equivalent overloaded methods) then you’ll recognise this.

Depending on how much method re-use you can share between tests, this may also be brittle and a lot of effort to maintain.  Both ways of doing things also lack clarity when lots of arguments are being passed around — the intent of the test (read: the interesting argument[s]) can be hidden by the noise of setting up safe defaults.  E.g. If you have 10 ‘normal’ objects and one badly formatted string that you’re using to make sure that an exception occurs, you want to focus on the argument that will cause the exception, not other parts.

Test Data Builders

So… what is this mythical Test Data Builder pattern?  It’s actually quite simple, though the syntax can look strange if you haven’t come across fluent interfaces before.

A Test Data Builder is an extension of a standard factory method.  The difference between a standard factory and a builder is the way that the builder wires things up.  A factory typically has a “Create” call which creates an instance of an object (or objects) in pre-defined configurations, or with some customisability provided via arguments in the Create call, or injected into the factory’s constructor.

A TDB varies this approach by setting up default, safe values to be used to instantiate the class under test.  When the builder’s constructor runs, it creates these defaults and stores them as fields.  There is usually a one to one correspondence of the class under test’s parameter list and the values stored in the builder.

The cool part is that anyone using the TDB can selectively modify these values by calling methods or setting properties on the TDB.  Finally, when the TDB has been configured satisfactorily for the test, its Build method is called, injecting its fields into the class under test’s constructor as arguments.

Nat Pryce posted an excellent article on Test Data Builders so I would implore you to read it before reading the rest of this post.

Terser is more gooder – C# 3.0

Once I’d got my head around the strange fluent interface syntax, I found that example to be invaluable.  It got me thinking: what if we could write these builders in an even more concise fashion?  Well, we can.  C# 3.0 can go one step further and, through the use of object initialisers, eliminate the need for method chaining.  This results in terser syntax still.

It’s simple: Instead of using a method per value change, we use a property instead.  Since object initialisers are run immediately after a constructor and are nicely grouped, it means we can create and configure our builder in one step.

The following code is provided merely to illustrate the syntax (there’s not much point in using a TDB on a class with so few parameters).  Here’s an overly simple example of a Person class to test.

Here’s the builder.  Notice that it has 3 auto properties that match the Person class’s constructor parameter names and types.  Default values are instantiated in the constructor, and the properties allow test writers to swap out the defaults for their own specific values.

Finally, here’s the test code itself.  Notice that the only arguments that are varied are the ones that are named in the test.  If the builder’s property is not set, the defaults held in the builder are used to construct the instance of the class under test.

If any of this is unclear, just paste the code into your IDE and step through it in your debugger to see what’s happening (you’ll have to remove the non existent methods & exception test, obviously!)


I’ve found the following advantages when using this pattern in tests with large amounts of setup and little commonality in object construction:

  1. Less fragile.  Since object creation is centralised and uses safe values by default, tests are more resistant to change compared to direct constructor calls.
  2. Terser test code (extremely important when setup is complicated)
  3. The intent of the test is clearer.  There is less noise in test code, so you can more easily pick out the arguments/interactions of interest.