Upcoming talks spring 2010

Sunday, 23 May 2010 16:11:37 UTC

In the next couple of weeks I will be giving a couple of talks in Copenhagen.

At Community Day 2010 I will be giving two talks on respectively Dependency Injection and TDD.

In early June I will be giving a repeat of my previous CNUG TDD talk.


Sneak view at Castle's WCF Facility

Tuesday, 18 May 2010 05:27:56 UTC

One of Castle Windsor's facilities addresses wiring up of WCF services. So far, the sparse documentation for the WCF Facility seems to indicate that you have to configure your container in a global.asax. That's not much to my liking. First of all, it reeks of ASP.NET, and secondly, it's not going to work if you expose WCF over protocols other than HTTP.

However, now that we know that a custom ServiceHostFactory is effectively a Singleton, a much better alternative is to derive from the WCF Facility's DefaultServiceHost class:

public class FooServiceHostFactory : 
    DefaultServiceHostFactory
{
    public FooServiceHostFactory()
        : base(FooServiceHostFactory.CreateKernel())
    {
    }
 
    private static IKernel CreateKernel()
    {
        var container = new WindsorContainer();
 
        container.AddFacility<WcfFacility>();
 
        container.Register(Component
            .For<FooService>()
            .LifeStyle.Transient);
        container.Register(Component
            .For<IBar>()
            .ImplementedBy<Bar>());
 
        return container.Kernel;
    }
}

Although it feels a little odd to create a container and then not really use it, but only its Kernel property, this works like a charm. It correctly wires up this FooService:

public class FooService : IFooService
{
    private readonly IBar bar;
 
    public FooService(IBar bar)
    {
        if (bar == null)
        {
            throw new ArgumentNullException("bar");
        }
 
        this.bar = bar;
    }
 
    #region IFooService Members
 
    public string Foo()
    {
        return this.bar.Baz;
    }
 
    #endregion
}

However, instead of the static CreateKernel method that creates the IKernel instance, I suggest that the WCF Facility utilizes the Factory Method pattern. As the WCF Facility has not yet been released, perhaps there's still time for that change.

In any case, the WCF Facility saves you from writing a lot of infrastructure code if you would like to wire your WCF services with Castle Windsor.


Comments

There's a plan to provide Facility's base ServiceHostFactory that you could use out of the box with very minimal anmount if XML config in your web.config/app.config file:

<installers>
<install assembly="Ploeh.AssemblyContainingWindsorInstallers"/>
</ installers>

See http://stw.castleproject.org/Windsor.Registering-Installers.ashx

Alternatively you could override protected IWindsorInstaller GetInstallers(); method and configure the container entirely in code.

Thoughts?
2010-05-18 08:24 UTC
That would definitely address most cases, including the one I'm currently looking at, although I'm not sure I understand your last sentence. Did you mean that I can implement a custom IWindsorInstaller? If so, that makes a lot of sense.

For the edge cases where adding an Installer isn't enough, I'd still prefer a Factory Method hook in DefaultServiceHostFactory, but being able to specify an Installer in web.config will likely address 90 percent (or more) of scenarios.

Looks good!
2010-05-18 08:38 UTC
In both cases you will need to provide your own implementation of IWindsorInstaller that will provide services and configuration to the container. The difference between the two approaches is as follows:

If you use Facility's default SH Factory it will look into your web.config for informations about how to configure itself.
ALternativelty you can provide your own subclass of the SH Factory, override its protected IWindsorInstaller[] GetInstallers(); method and then you'll be able to configure the container without using config file.
2010-05-18 08:45 UTC
Why would you prefer factory method instead of just pointing to installers? What do you need to do that the other approach can't address?
2010-05-18 08:47 UTC
Thanks for your explanation. I think that sounds very promising. As far as I can tell, this is still in the future, right? I don't see any GetInstallers() on DefaultServiceHostFactory right now (based on the code I downloaded and compiled last week).

Don't get me wrong on the Factory Method thing. I don't expect to need it often (if at all), but I just think it would be a good OCP thing to do... Off the top of my head, I can't remember whether there are things you can do to a container that you can't do from an Installer. Maybe there aren't...
2010-05-18 09:05 UTC
you're right, GetInstallers() is not there yet, (same as specifying installers in xml is part of trunk, not v2.1).

I do intend to leave the door open with factory method for people who can't use xml even if it's so minimal (or feel sick when even thinking about xml), but as you said - there really isn't anything you couldn't do from installer so I imagine it would be for emergency cases only.
2010-05-18 09:15 UTC

ServiceHostFactory lifetime

Monday, 17 May 2010 05:42:33 UTC

For a while I've been wondering about the lifetime behavior of custom ServiceHostFactory classes hosted in IIS. Does IIS create an instance per request? Or a single instance to handle all requests?

I decided to find out, so I wrote a little test service. The conclusion seems to be that there is only a single instance that servers as a factory for all requests. This is very fortunate, since it gives us an excellent place to host a DI Container. The container can then manage the lifetime of all components, including Singletons that will live for the duration of the process.

If you are curious how I arrived at this conclusion, here's the code I wrote. I started out with this custom ServiceHostFactory:

public class PocServiceHostFactory : ServiceHostFactory
{
    private static int number = 1;
 
    public PocServiceHostFactory()
    {
        Interlocked.Increment(
            ref PocServiceHostFactory.number);
    }
 
    protected override ServiceHost CreateServiceHost(
        Type serviceType, Uri[] baseAddresses)
    {
        return new PocServiceHost(
            PocServiceHostFactory.number, serviceType,
            baseAddresses);
    }
}

The idea is that every time a new instance of ServiceHostFactory is created, the static number is incremented.

The PocServiceHostFactory just forwards the number to the PocServiceHost:

public class PocServiceHost : ServiceHost
{
    public PocServiceHost(int number, Type serviceType,
        Uri[] baseAddresses)
        : base(serviceType, baseAddresses)
    {
        foreach (var cd in 
            this.ImplementedContracts.Values)
        {
            cd.Behaviors.Add(
                new NumberServiceInstanceProvider(
                    number));
        }
    }
}

The PocServiceHost just forwards the number to the NumberServiceInstanceProvider:

public class NumberServiceInstanceProvider : 
    IInstanceProvider, IContractBehavior
{
    private readonly int number;
 
    public NumberServiceInstanceProvider(int number)
    {
        this.number = number;
    }
 
    #region IInstanceProvider Members
 
    public object GetInstance(
        InstanceContext instanceContext,
        Message message)
    {
        return this.GetInstance(instanceContext);
    }
 
    public object GetInstance(
        InstanceContext instanceContext)
    {
        return new NumberService(this.number);
    }
 
    public void ReleaseInstance(
        InstanceContext instanceContext,
        object instance)
    {
    }
 
    #endregion
 
    #region IContractBehavior Members
 
    public void AddBindingParameters(
        ContractDescription contractDescription,
        ServiceEndpoint endpoint,
        BindingParameterCollection bindingParameters)
    {
    }
 
    public void ApplyClientBehavior(
        ContractDescription contractDescription,
        ServiceEndpoint endpoint,
        ClientRuntime clientRuntime)
    {
    }
 
    public void ApplyDispatchBehavior(
        ContractDescription contractDescription,
        ServiceEndpoint endpoint,
        DispatchRuntime dispatchRuntime)
    {
        dispatchRuntime.InstanceProvider = this;
    }
 
    public void Validate(
        ContractDescription contractDescription,
        ServiceEndpoint endpoint)
    {
    }
 
    #endregion
}

The relevant part of NumberServiceInstanceProvider is the GetInstanceMethod that simply forwards the number to the NumberService:

public class NumberService : INumberService
{
    private readonly int number;
 
    public NumberService(int number)
    {
        this.number = number;
    }
 
    #region INumberService Members
 
    public int GetNumber()
    {
        return this.number;
    }
 
    #endregion
}

As you can see, NumberService simply returns the injected number.

The experiment is now to host NumberService in IIS using PocServiceHostFactory. If there is only one ServiceHostFactory per application process, we would expect that the same number (2) is returned every time we invoke the GetNumber operation. If, on the other hand, a new instance of ServiceHostFactory is created per request, we would expect the number to increase for every request.

To test this I spun up a few instances of WcfTestClient.exe and invoked the operation. It consistently returns 2 across multiple clients and multiple requests. This supports the hypothesis that there is only one ServiceHostFactory per service process.


Comments

onof
There's a project on codeplex

http://containerservicehost.codeplex.com/documentation
2010-05-17 07:10 UTC

Fun with literal extensions and Ambient Context

Tuesday, 27 April 2010 04:24:25 UTC

My book contains a section on the Ambient Context pattern that uses a TimeProvider as an example. It's used like this:

this.closedAt = TimeProvider.Current.UtcNow;

Yesterday I was TDDing a state machine that consumes TimeProvider and needed to freeze and advance time at different places in the test. Always on the lookout for making unit tests more readable, I decided to have a little fun with literal extensions and TimeProvider. I ended up with this test:

// Fixture setup
var fixture = new WcfFixture();
 
DateTime.Now.Freeze();
 
fixture.Register(1.Minutes());
var sut = fixture.CreateAnonymous<CircuitBreaker>();
sut.PutInOpenState();
 
2.Minutes().Pass();
// Exercise system
sut.Guard();
// Verify outcome
Assert.IsInstanceOfType(sut.State,
    typeof(HalfOpenCircuitState));
// Teardown

There are several items of note. Imagine that we can freeze time!

DateTime.Now.Freeze();

With the TimeProvider and an extension method, we can:

internal static void Freeze(this DateTime dt)
{
    var timeProviderStub = new Mock<TimeProvider>();
    timeProviderStub.SetupGet(tp => tp.UtcNow).Returns(dt);
    TimeProvider.Current = timeProviderStub.Object;
}

This effectively sets up the TimeProvider to always return the same time.

Later in the test I state that 2 minutes pass:

2.Minutes().Pass();

I particularly like the grammatically correct English. This is accomplished with a combination of a literal extension and changing the state of TimeProvider.

First, the literal extension:

internal static TimeSpan Minutes(this int m)
{
    return TimeSpan.FromMinutes(m);
}

Given the TimeSpan returned from the Minutes method, I can now invoke the Pass extension method:

internal static void Pass(this TimeSpan ts)
{
    var previousTime = TimeProvider.Current.UtcNow;
    (previousTime + ts).Freeze();
}

Note that I just add the TimeSpan to the current time and invoke the Freeze extension method with the new value.

Last, but not least, I should point out that the PutInOpenState method isn't some smelly test-specific method on the SUT, but rather yet another extension method.


Changing Windsor lifestyles after the fact

Monday, 26 April 2010 05:09:42 UTC

I recently had the need to change the lifestyles of all components in a WindsorContainer (read on to the end if you want to know why). This turned out to be amazingly simple to do.

The problem was this: I had numerous components registered in a WindsorContainer, some of them as Singletons, some as Transients and yet again some as PerWebRequest. Configuration was even defined in numerous IWindsorInstallers, including some distributed XML files. I now needed to spin up a second container with the same configuration as the first one, except that the lifestyles should be all Singletons across the board.

This can be easily accomplished by implementing a custom IContributeComponentModelConstruction type. Here's a simple example:

Consider this IWindsorInstaller:

public class FooInstaller : IWindsorInstaller
{
    #region IWindsorInstaller Members
 
    public void Install(IWindsorContainer container,
        IConfigurationStore store)
    {
        container.Register(Component
            .For<IFoo>()
            .ImplementedBy<Foo>()
            .LifeStyle.Transient);
    }
 
    #endregion
}

The important point to notice is that it registers the lifestyle as Transient. In other words, this container will always return new Foo instances:

var container = new WindsorContainer();
container.Install(new FooInstaller());

We can override this behavior by adding this custom IContributeComponentModelConstruction:

public class SingletonEqualizer :
    IContributeComponentModelConstruction
{
    public void ProcessModel(IKernel kernel, 
        ComponentModel model)
    {
        model.LifestyleType = LifestyleType.Singleton;
    }
}

In this very simple example, I always set the lifestyle type to the same value, but obviously we can write as complex code in the ProcessModel method as we would like. We can now configure the container like this:

var container = new WindsorContainer();
container.Kernel.ComponentModelBuilder
    .AddContributor(new SingletonEqualizer());
container.Install(new FooInstaller());

With this configuration we will now get the same instance of Foo every time we Resolve IFoo.

We did I need this? Because my application is a web application and I'm using the PerWebRequest lifestyle in a number of places. However, I needed to spin up a second container that would compose object hierarchies for a background process. This background process needs the same component configuration as the rest of the application, but can't use the PerWebRequest lifestyle as there will be no web request available to the background process. Hence the need to change lifestyles across the board.


Why I'm migrating from MSTest to xUnit.net

Monday, 26 April 2010 04:30:49 UTC

About a month ago I decided to migrate from MSTest to xUnit.net, and while I am still in the process, I haven't regretted it yet, and I don't expect to. AutoFixture has already moved over, and I'm slowly migrating all the sample code for my book.

Recently I was asked why, which prompted me to write this post.

I'm not moving away from MSTest for one single reason. It's rather like lots of small reasons.

When I originally started out with TDD, I used nUnit - it was more or less the only unit testing framework available for .NET at the time. When MSTest came, the change was natural, since I worked for Microsoft at the time. This is not the case anymore, but it still took me most of a year to finally abandon MSTest.

There was one thing that really made me cling to MSTest, and that was the IDE integration, but over time, I started to realize that this was the only reason, and even that was getting flaky.

When I started to think about all the things that left me dissatisfied, making the decision was easy:

  • First of all, MSTest isn't extensible, but xUnit.net is. In xUnit.net, I can extend the Fact or Theory attributes (and I intent to), while in MSTest, I will have to play with the cards I've been dealt. I think I could live with all the other issues if I could just have this one, but no.
  • MSTest has no support for parameterized test. xUnit.net does (via the Theory attribute).
  • MSTest has no Assert.Throws, although I requested this feature a long time ago. Now Visual Studio 2010 is out, but Assert.Throws is still nowhere in sight.
  • MSTest has no x64 support. Tests always run as x86. Usually it's no big deal, but sometimes it's a really big deal.
  • In MSTest, to write unit tests, you must create a special Unit Test Project, and those are only available for C# and VB.net. Good luck trying to write unit tests in a more exotic .NET language (like F# on Visual Studio 2008). xUnit.net doesn't have this problem.
  • MSTest uses Test Lists and .vsmdi files to maintain test lists. Why? I don't care, I just want to execute my tests, and the .vsmdi files are in the way. This is particularly bad when you use TFS, but I'm also moving away from TFS, so that wouldn't have continued to be that much of an issue. Still: try having more than one .sln file with unit tests in the same folder, and watch funny things happen because they need to share the same .vsmdi file.
  • I suppose it's because of the .vsmdi files, but sometimes I get a Test run error if I delete a test and run the tests immediately after. That's a false positive, if anyone cares.
  • MSTest gives special treatment to its own AssertionException, which gets nice formatting in the Test Results window. All other exceptions (like verification exceptions thrown by Moq or Rhino Mocks are rendered near-intelligible because MSTest thinks it's very important to report the fully qualified name of the exception before its message. Most of the time, you have to open the Test Details window to see the exception message.
  • Last, but not least, I often get cryptic exception messages like this one: Column 'id_column, runid_column' is constrained to be unique.  Value '8c84fa94-04c1-424b-9868-57a2d4851a1d, d7471c5e-522f-43d3-b2c5-8f5cab55af0e' is already present. This appears in a very annoying modal MessageBox, but clicking OK and retrying usually works, although sometimes it even takes two or three attempts before I can get past this error.

It not one big thing, it's just a lot of small, but very annoying things. After three iterations (VS2005, VS2008 and now VS2010) these issue have still to be addressed, and I got tired of waiting.

So far, I can only say that I have none of these problems with xUnit.net and the IDE integration provided by TestDriven.NET. It's just a much smoother experience with much less friction.


Comments

Hi Mark,

Interesting post about moving away from "out-of-the-box" Microsoft tools. I've made this move about a year ago, and I can't regret about it.

Another point that you mentioned in your post and that really caught my attention was the fact that you are also moving away from TFS. Since I'm starting my own startup here, the budget is really short and we are looking for cheaper alternatives to TFS.

Here, we really like Mercurial HG and we are basing out SCM on it. However, I'm having difficulty finding tools for bug and feature tracking. Can you share with me in which direction you are moving away from TFS?
2010-04-26 13:59 UTC
Personally, I also use Hg for SCM.

In Safewhere, we are currenlty trying out AgileZen for work item tracking. For AutoFixture, I just use the tools provided with CodePlex.
2010-04-26 16:32 UTC
I started with NUnit, and gave a quick shot at MSTest, but never made the transition, because I couldn't see any upside. Could you comment a bit on why you picked xUnit over NUnit? I haven't tried it yet, but from what I saw in the docs, the syntax is pretty interesting; first time in a while that I see a framework which seems to re-think unit testing, rather than improve on JUnit.
2010-04-26 21:15 UTC
There are two main reasons that I prefer xUnit.net over NUnit, but both may be due to ignorance about NUnit on my part. The last time I did serious work with NUnit must have been back in 2005.

One reason is that xUnit.net has a pretty good extensibility story, and as I do have some plans in that direction, that's a pretty big issue for me. Last time I checked, the extensibility story for NUnit didn't match xUnit.net.

NUnit has a design bug when it comes to Fixture management, because it creates only a single instance of a test class and invokes all the test methods on that instance. This may have been fixed since the last time I looked, but in any case, I better like xUnit.net's philosphy of using the test class' constructor for Fixture Setup (if any) and implementing IDisposable for Fixture Teardown.

As I said, both items are based on somewhat dated knowledge on my part, so none of them may apply anymore.
2010-04-26 21:26 UTC
Thanks for writing this up, the tooling built into VS for MSTest makes it very attractive but it still gets a lot of hate. Nice to know why :)
2010-05-11 10:36 UTC
Is the MSTest code going to also be available somewhere? I'd hate to have to constantly be translating for code you already have available for us. - twitter @MaslowJax
2010-06-19 16:46 UTC
I'm not sure exactly to which MSTest code you are referring, but in general I don't plan to change the existing MSTest code I've posted here on the blog. However, new tests are likely to appear with xUnit.net. In any case, when it comes to unit testing examples I don't think the differences are all that important. In most cases it's just a question of differently named attributes and slightly different Assert syntax...
2010-06-20 06:39 UTC
Fabricio
MSTest support parametrized tests using Pex
2012-03-27 15:17 UTC

AutoFixture 1.1

Saturday, 10 April 2010 10:25:23 UTC

AutoFixture 1.1 is now available on the CodePlex site! Compared to the Release Candidate, there are no changes.

The 1.1 release page has more details about this particular release, but essentially this is the RC promoted to release status.

Release 1.1 is an interim release that addresses a few issues that appeared since the release of version 1.0. Work continues on AutoFixture 2.0 in parallel.


Dependency Injection is Loose Coupling

Wednesday, 07 April 2010 19:49:11 UTC

It seems to me that I've lately encountered a particular mindset towards Dependency Injection (DI). People seem to think that it's only really good for replacing one data access implementation with another. Once you get to that point, you know that the following argument isn't far behind:

“That's all well and good, but we know for certain that we will never exchange [insert name of RDBMS here] with anything else in this application.”

Apart from the hubris of making such a bold statement about the future of any software endeavor, such a statement reveals the narrow view on DI that its only purpose is for replacing data access components - and perhaps for unit testing.

Those are relevant reasons for using DI, but they are only some of the reasons. Let's briefly revisit why we employ DI.

We use DI to enable loose coupling.

DI is only a means to an end. Even if you never intend to replace your database and even if you never want to write a single unit test, DI still offers benefits in form of a more maintainable code base. The loose coupling gives you better separation of concerns because it allows you to apply the Open/Closed Principle.

Example coming right up:

Imagine that we need to implement a PrécisViewModel class with a TopSellers property that returns an IEnumerable<string>. To implement this class, we have a data access component. Let's use the ubiquitous Repository pattern and define IProductRepository to see where that leads us:

public interface IProductRepository
{
    IEnumerable<Product> SelectTopSellers();
}

We can now implement PrécisViewModel like this:

public class PrécisViewModel
{
    private readonly IProductRepository repository;
 
    public PrécisViewModel(IProductRepository repository)
    {
        if (repository == null)
        {
            throw new ArgumentNullException("repository");
        }
 
        this.repository = repository;
    }
 
    public IEnumerable<string> TopSellers
    {
        get
        {
            var topSellers = 
                this.repository.SelectTopSellers();
            return from p in topSellers
                   select p.Name;
        }
    }
}

Nothing fancy is going on here. It's just straight Constructor Injection at work.

Obviously, we can now implement and use a SQL Server-based repository:

var repository = new SqlProductRepository();
var vm = new PrécisViewModel(repository);

So what does all this loose coupling buy us? It doesn't seem to help us a lot.

The real benefit is not yet apparent, but it should become more obvious when we start adding requirements. Let's start with some caching. It turns out that the SelectTopSellers implementation is slow, so we would like to add some caching somewhere.

Where should we add this caching functionality? Without loose coupling, we would more or less be constrained to adding it to either PrécisViewModel or SqlProductRepository, but both have issues:

  • First of all we would be violating the Single Responsibility Principle (SRP) in both cases.
  • If we implement caching in PrécisViewModel, other consumers of the SelectTopSellers would not benefit from it.
  • If we implement caching in SqlProductRepository, it wouldn't be available for any other IProductRepository implementations.

Since the premise for this post is that we will never use any other database than SQL Server, implementing caching directly in SqlProductRepository sounds like the correct choice, but we would still be violating the SRP, and thus making our code more difficult to maintain.

A better solution is to introduce a caching Decorator like this one:

public class CachingProductRepository : IProductRepository
{
    private readonly ICache cache;
    private readonly IProductRepository repository;
 
    public CachingProductRepository(
        IProductRepository repository, ICache cache)
    {
        if (repository == null)
        {
            throw new ArgumentNullException("repository");
        }
        if (cache == null)
        {
            throw new ArgumentNullException("cache");
        }
 
        this.cache = cache;
        this.repository = repository;
    }
 
    #region IProductRepository Members
 
    public IEnumerable<Product> SelectTopSellers()
    {
        return this.cache
            .Retrieve<IEnumerable<Product>>("topSellers",
                this.repository.SelectTopSellers);
    }
 
    #endregion
}

For completeness sake is here the definition of ICache:

public interface ICache
{
    T Retrieve<T>(string key, Func<T> readThrough);
}

The point is that CachingProductRepository extends any IProductRepository we provide to it (including SqlProductRepository) without modifying it. Thus, we have satisfied both the OCP and the SRP.

Just to drive home the point, let us assume that we also wish to record execution times for various methods for purposes of SLA compliance. We can do this by introducing yet another Decorator:

public class PerformanceMeasuringProductRepository : 
    IProductRepository
{
    private readonly IProductRepository repository;
    private readonly IStopwatch stopwatch;
 
    public PerformanceMeasuringProductRepository(
        IProductRepository repository, 
        IStopwatch stopwatch)
    {
        if (repository == null)
        {
            throw new ArgumentNullException("repository");
        }
        if (stopwatch == null)
        {
            throw new ArgumentNullException("stopwatch");
        }
 
        this.repository = repository;
        this.stopwatch = stopwatch;
    }
 
    #region IProductRepository Members
 
    public IEnumerable<Product> SelectTopSellers()
    {
        var timer = this.stopwatch
            .StartMeasuring("SelectTopSellers");
        var topSellers = 
            this.repository.SelectTopSellers();
        timer.StopMeasuring();
        return topSellers;
    }
 
    #endregion
}

Once again, we modified neither SqlProductRepository nor CachingProductRepository to introduce this new feature. We can implement security and auditing features by following the same principle.

To me, this is what loose coupling (and DI) is all about. That we can also replace data access components and unit test using dynamic mocks are very fortunate side effects, but the loose coupling is valuable in itself because it enables us to write more maintainable code.

We don't even need a DI Container to wire up all these repositories (although it sure would could be helpful). Here's how we can do it with Pure DI:

IProductRepository repository =
    new PerformanceMeasuringProductRepository(
        new CachingProductRepository(
            new SqlProductRepository(), new Cache()
            ),
        new RealStopwatch()
    );
var vm = new PrécisViewModel(repository);

The next time someone on your team claims that you don't need DI because the choice of RDBMS is fixed, you can tell them that it's irrelevant. The choice is between DI and Spaghetti Code.


Comments

Arnis L
That was marvelous post. Never thought about this kind of approach.

Btw, i never figured out if there is anything why service locator isn't anti pattern. :)
2010-04-08 11:27 UTC
Thanks :)

I'm not sure I understand your comment regarding Service Locator. It is an anti-pattern :)

No, seriously, I never expected the entire world to just accept my word as gospel, and there are many people who disagree on this point. Did you have something specific in mind?
2010-04-08 11:37 UTC
I recently listened to a short talk by the MonoTorrent author at FOSDEM 2010. His presentation included an explanation of how (after running into maintenance hell first) he had separated the different concerns in his bittorrent piece picking code by implementing it as a series of decorators.

For me the interesting thing about the talk was that apparently this "separation of concerns" thing had been an important enough discovery for him that it warranted the use of half the presentation time to explain, with the other half being spent talking about the dangers of multi-threading :-)
2010-04-09 07:24 UTC
Kshitij
Love, the blog spot. thanks for showing DI in action.
2010-04-19 00:01 UTC
Totally off-topic comment, but I believe this is the first time I witness C# code with acute accents :) Do you really use accents in your code?
2010-04-26 21:20 UTC
He he, no, normally I don't, but sometimes when writing sample code I like taking advantage of the fact that C# is based on Unicode. Somewhere here, I also have a sample that uses Danish characters (æ, ø or å), but I can't remember which post it was :)
2010-04-26 21:30 UTC
Hey Mark,
A little off-topic, but how'd you implement Cache to force evaluation if it gets passed a Func<IEnumerable<Something>>? Else it will just cache the query.
2010-10-08 22:17 UTC
Yes, you are right. Perhaps it will just cache the query - it actually depends on what the concrete implementation is. It may be an array or List<T>, in which case there is no issue.

However, we could always specialize the implementation of the cache so that if T was IEnumerable, we'd invoke ToList() on it before caching the result.
2010-10-09 07:04 UTC
Geat post, this shows clearly how you can chain functionality without violation OCP and SRP
2011-04-07 08:34 UTC
Tom Stickel
Awesome as usual. Once I drank in the Mark Seemann punch, I'm addicted to following how to do DI properly.
Thanks Mark. Any books from you scheduled for this year or the next?

2012-01-15 19:04 UTC
Thanks, Tom. No new book scheduled right now :)
2012-01-15 19:33 UTC
Alex
Hi Mark!

What if IProductRepository has 15 methods but only one method should be cached?

Or what if I don't need always the cache? So I have a ProductService that needs a IProductRepository. For 5 cases the ProducrtService would need the CachingProductRepository and for the rest the standard ProductRepository?
2012-09-12 11:46 UTC
If you have 15 methods and only one should be cached, you can still cache the one method with a Decorator. The remaining 14 methods on that Decorator can be implemented as pure delegation.

However, if you have this scenario, could it be that the interface violates the Interface Segregation Principle?
2012-09-12 11:56 UTC

Mapping types with AutoFixture

Tuesday, 06 April 2010 05:22:32 UTC

In my previous posts I demonstrated interaction-based unit tests that verify that a pizza is correctly being added to a shopping basket. An alternative is a state-based test where we examine the contents of the shopping basket after exercising the SUT. Here's an initial attempt:

[TestMethod]
public void AddWillAddToBasket()
{
    // Fixture setup
    var fixture = new Fixture();
    fixture.Register<IPizzaMap>(
        fixture.CreateAnonymous<PizzaMap>);
 
    var basket = fixture.Freeze<Basket>();
 
    var pizza = fixture.CreateAnonymous<PizzaPresenter>();
 
    var sut = fixture.CreateAnonymous<BasketPresenter>();
    // Exercise system
    sut.Add(pizza);
    // Verify outcome
    Assert.IsTrue(basket.Pizze.Any(p => 
        p.Name == pizza.Name), "Basket has added pizza.");
    // Teardown
}

In this case the assertion examines the Pizze collection (you did know that the plural of pizza is pizze, right?) of the frozen Basket to verify that it contains the added pizza.

The tricky part is that the Pizze property is a collection of Pizza instances, and not PizzaPresenter instances. The injected IPizzaMap instance is responsible for mapping from PizzaPresenter to Pizza, but since we are rewriting this as a state-based test, I thought it would also be interesting to write the test without using Moq. Instead, we can use the real implementation of IPizzaMap, but this means that we must instruct AutoFixture to map from the abstract IPizzaMap to the concrete PizzaMap.

We see that happening in this line of code:

fixture.Register<IPizzaMap>(
    fixture.CreateAnonymous<PizzaMap>);

Notice the method group syntax: we pass in a delegate to the CreateAnonymous method, which means that every time the fixture is asked to create an IPizzaMap instance, it invokes CreateAnonymous<PIzzaMap>() and uses the result.

This is, obviously, a general-purpose way in which we can map compatible types, so we can write an extension method like this one:

public static void Register<TAbstract, TConcrete>(
    this Fixture fixture) where TConcrete : TAbstract
{
    fixture.Register<TAbstract>(() =>
        fixture.CreateAnonymous<TConcrete>());
}

(I'm slightly undecided on the name of this method. Map might be a better name, but I just like the equivalence to some common DI Containers and their Register methods.) Armed with this Register overload, we can now rewrite the previous Register statement like this:

fixture.Register<IPizzaMap, PizzaMap>();

It's the same amount of code lines, but I find it slightly more succinct and communicative.

The real point of this blog post, however, is that you can map abstract types to concrete types, and that you can always write extension methods to encapsulate your own AutoFixture idioms.


Comments

I also prefer Register (instead of Map). Because most of the times it will be like that: registering an interface to an implementation.
2011-03-13 10:06 UTC

AutoFixture 1.1 RC1

Friday, 02 April 2010 06:44:27 UTC

AutoFixture 1.1 Release Candidate 1 is now available on the CodePlex site.

Users are encouraged to evaluate this RC and submit feedback. If no bugs or issues are reported within the next week, we will promote RC1 to version 1.1.

The release page has more details about this particular release.


Page 30 of 38

"Our team wholeheartedly endorses Mark. His expert service provides tremendous value."
Hire me!