ploeh blog : Dependency Injection

An Overview of Unit Testing Duplex WCF Services and Clients

ploeh — Sat, 12 Jul 2008 08:50:00 GMT

In the last couple of posts, I've demonstrated how to isolate implementation from WCF contract definition and behavior in a duplex communication scenario. These posts have been rather detailed, so it occurred to me that you might benefit from an overview.

The main goal was to ensure testability of implementations of both service and client. While the contracts reference WCF (System.ServiceModel), the implementations themselves only reference the contracts, and not WCF.

This diagram illustrates dependencies between the various libraries. The left side contains server-side components, while the right side contains client-side components. The only shared components are WCF and the Contract library.

Note that neither StuffServer nor StuffAgent has any dependency on System.ServiceModel, although they have a dependency on Contract. The same is true for both unit test projects.

The top boxes on both sides (MyServer and MyClient) are hypothetical top-level executables such as I've discussed before, although never shown any code from. These Humble Executables tie everything together by referencing all relevant libraries, but if you prefer, you can just as well use a configurable Dependency Injection container - Oran Dennison explains how to do this on Spring.NET, while Ayende has a Windsor ServiceHostFactory.

Here are the main posts on the subject:

If you would like to take a closer look at my sample code, I've attached it to this post. As usual, the standard disclaimers apply.

Unit Testing Duplex WCF Clients

ploeh — Wed, 09 Jul 2008 00:06:00 GMT

In my previous post, I explained how to unit test a WCF service with callbacks. Since the scenario involves duplex communication, the service is also a client, and vice versa, so it's only reasonable to look at the 'client' as well, to examine how to best approach unit testing such a beast.

Since both ends both act as sender and receiver, they are each both client and service. None the less, there's still a clear distinction, since the client is the party that initiates and terminates a session, whereas the service is always ready and available for whatever client that may come along.

Ensuring proper isolation and testability is most difficult for the service, which was why I decided to tackle that issue first. Making the client testable is much easier, and I'll describe how to do that here by continuing the example from my former post.

When writing the client, the only thing I really need to abstract away is the creation of the WCF proxy and its callback instance.

When you look at the standard WCF documentation for duplex clients, a duplex proxy can be created by a DuplexChannelFactory<TChannel> like this:

DuplexChannelFactory<IStuffService> cf =

    new DuplexChannelFactory<IStuffService>(callbackService,

        binding, remoteAddress);

You can then invoke CreateChannel on the cf instance to get an instance of an IStuffService proxy.

However, now that you have decided to implement your client without any reference to WCF, the use of DuplexChannelFactory<TChannel> and its ilk from within that library is not permitted (and should indeed be impossible, since you don't have a reference to System.ServiceModel).

What the client really needs is something that can create an instance of an IStuffService proxy, while itself receiving an instance of IStuffCallbackService (which is the type of the callbackService parameter above). In other words, I'll need to define an abstraction that takes IStuffCallbackService as input and returns IStuffService.

In a move very similar to the approach described previously, a Func<IStuffCallbackService, IStuffService> is just what we need. Hence, a rudimentary implementation of StuffClient would be similar to this:

public class StuffClient : IStuffCallbackService

    private readonly Func<IStuffCallbackService, IStuffService> createProxy_;

    public StuffClient(Func<IStuffCallbackService, IStuffService> proxyCreator)

        if (proxyCreator == null)

            throw new ArgumentNullException("proxyCreator");

        this.createProxy_ = proxyCreator;

    public void DoStuff(string stuff)

        IStuffService proxy = this.createProxy_(this);

        proxy.DoStuff(stuff);

        // Remeber to safely dispose of proxy

    // Other members, including IStuffCallbackService Members...

The abstract proxy creator is required by way of Constructor Injection, and is used in the DoStuff method to create an IStuffService proxy instance, which may or may not be a WCF proxy.

If the proxy instance is a real WCF proxy, it will implement IDisposable and should be properly closed. There are several strategies for dealing with this situation, but to keep the example as simple as possible, I've chosen to omit this particular aspect, and leave it as an exercise for the interested reader :)

Although I have yet to show the actual implementation, note that StuffClient implements IStuffCallbackService, so it can return itself to the createProxy_ delegate instance as the callback service. Obviously, if you use the same object as both sender and receiver, you need to do so in a thread-safe manner, but since I can, in this particular context, bask in the luxury of writing sample code, I choose to ignore thread-safety completely :)

#region IStuffCallbackService Members

public void StuffWasDone(string result)

    this.stuffResults_.Add(result);

#endregion

where stuffResults_ is a List<string>.

Unit testing StuffClient is now fairly simple. We'll need an implementation of IStuffService to act as a Test Double, so I've created a simple SpyStuffService class that records all the stuff strings in a List<string> called Stuffs.

First of all, we need to ensure that the proxyCreator delegate instance receives a proper instance of IStuffCallbackService as input:

[TestMethod]

public void DoStuffWillCreateProxyByPassingNonNullCallback()

    // Fixture setup

    string anonymousStuff = "ploeh";

    SpyStuffService dummy = new SpyStuffService();

    StuffClient sut = new StuffClient(callbackService =>

            Assert.IsNotNull(callbackService,

                "Callback service");

            return dummy;

});

    // Exercise system

    sut.DoStuff(anonymousStuff);

    // Verify outcome (done by inline mock);

    // Teardown

A bit unusually, test verification happens inside the delegate defined by the lambda expression passed to the constructor of StuffClient - a technique I call an Inline Mock. Since C# is strongly typed, I can be assured that if callbackService is not null, it will be an instance of IStuffCallbackService.

Next, we may want to verify that when DoStuff is invoked, data will be transferred to the service:

[TestMethod]

public void DoStuffWillSendStuffToService()

    // Fixture setup

    string expectedStuff = "ploeh";

    SpyStuffService spy = new SpyStuffService();

    StuffClient sut =

        new StuffClient(callbackService => spy);

    // Exercise system

    sut.DoStuff(expectedStuff);

    // Verify outcome

    Assert.AreEqual<string>(expectedStuff,

        spy.Stuffs.First(), "Stuff");

    // Teardown

The Spy is passed to the SUT in the constructor, and later inspected in the verification phase. Pretty classic four-phase unit test setup...

Finally, we may want to test the SUT's implementation of IStuffCallbackService:

[TestMethod]

public void StuffWasDoneWillAddResultToStuffResultList()

    // Fixture setup

    string expectedStuff = "ploeh";

    SpyStuffService dummy = new SpyStuffService();

    StuffClient sut =

        new StuffClient(callbackService => dummy);

    // Exercise system

    sut.StuffWasDone(expectedStuff);

    // Verify outcome

    Assert.AreEqual<string>(expectedStuff,

        sut.StuffResults.First(), "Stuff result");

    // Teardown

At this point, the SpyStuffService instance is not used by the SUT, but we need it for the Func<IStuffCallbackService, IStuffService> instance used in the StuffClient constructor, so it's a classic example of a Test Dummy.

The test invokes the StuffWasDone method and subsequently verifies that the string passed to it becomes available in the StuffResults list, so again, it's really just a standard four-phase unit test.

If you've managed to read this far, I owe it to you to show how to set up StuffClient with a real WCF proxy. Remember, this must be done in another library that can reference System.ServiceModel, since the library where StuffClient is implemented must not reference WCF. The most natural place to do this is in a Humble Object, such as a top-level executable, as described here.

StuffClient client = new StuffClient(callbackService =>

        DuplexChannelFactory<IStuffService> cf =

            new DuplexChannelFactory<IStuffService>(callbackService,

                binding, remoteAddress);

        return cf.CreateChannel();

});

Note that this is the place where WCF reappears after its long absence. The StuffClient implementation has no dependency on WCF, and testability is ensured.

Update (2008-07-12): I've just posted an overview of the solution, as well as all the sample code.

Modifying Behavior of WCF-Free Service Implementations

ploeh — Fri, 27 Jun 2008 23:55:00 GMT

In my previous post, I explained how to implement a WCF service without referencing WCF. In simple cases, it works as described, but you may soon find yourself in a situation where you need to modify the behavior of the service when it's hosted by WCF.

Perhaps you need to control the service's ConcurrencyMode, or perhaps you need to set UseSynchronizationContext. These options are typically controlled by the ServiceBehaviorAttribute.

You may also want to provide an IInstanceProvider via a custom attribute that implements IContractBehavior.

However, you can't set these attributes on the service implementation itself, since it mustn't have a reference to System.ServiceModel.

In the rest of this post, I'll provide an example of how to achieve such results while still keeping WCF out of the service implementation.

Consider this service implementation:

public class StuffService : IStuffService

    private readonly Func<IStuffCallbackService> createCallbackChannel_;

    public StuffService(Func<IStuffCallbackService> callbackCreator)

        if (callbackCreator == null)

            throw new ArgumentNullException("callbackCreator");

        this.createCallbackChannel_ = callbackCreator;

    // IStuffService members here...

There are many cases (Dependency Injection is a common reason) where a a non-default constructor is desirable, so if you are wondering about this weird-looking Func<IStuffCallbackService> parameter, just consider that it might as well have been some other type of dependency. In a later post (edit 2008.06.29: available here), it will become apparent just why the constructor takes this specific input - for now, the important point is that the service implementation only has one, non-default constructor, and that it will throw if passed a null value.

Since WCF by default manages a service instance's lifetime, and the default behavior is to create a new instance per request, WCF requires the service to have a default constructor; that is, unless an IInstanceProvider is provided.

IInstanceProvider is defined in System.ServiceModel, so I can't implement this interface directly in the service library; instead, I create a new library that defines the WCF hosting behavior for the service. This library references both System.ServiceModel and the service library (the library that contains StuffService), so essentially, it's the library that sits on top of the dependency hierarchy and wires everything together.

In this library, I can implement IInstanceProvider via an IContractBehavior to provide new instances of StuffService:

public class StuffInstancingBehavior :

    IContractBehavior, IInstanceProvider

    #region IInstanceProvider Members

    public object GetInstance(InstanceContext instanceContext,

        Message message)

        return this.GetInstance(instanceContext);

    public object GetInstance(InstanceContext instanceContext)

        return new StuffService(() =>

            OperationContext.Current.

            GetCallbackChannel<IStuffCallbackService>());

    public void ReleaseInstance(InstanceContext instanceContext,

        object instance) { }

    #endregion

    #region IContractBehavior Members

    public void AddBindingParameters(ContractDescription description,

        ServiceEndpoint endpoint,

        BindingParameterCollection bindingParameters) { }

    public void ApplyClientBehavior(ContractDescription description,

        ServiceEndpoint endpoint, ClientRuntime clientRuntime) { }

    public void ApplyDispatchBehavior(ContractDescription description,

        ServiceEndpoint endpoint, DispatchRuntime dispatchRuntime)

        dispatchRuntime.InstanceProvider = this;

    public void Validate(ContractDescription description,

        ServiceEndpoint endpoint) { }

    #endregion

There are really only two lines of code of interest in this code listing: ApplyDispatchBehavior associates this IInstanceProvider implementation with the DispatchRuntime, and the GetInstance method creates the StuffService instance itself.

Notice that while we will not accept the use of OperationContext.Current in the service library, it's perfectly legal to use it here.

Applying an IEndpointBehavior can be done either via configuration or by programmatically adding it to the ServiceHost before opening it.

Since WCF will not be able to create an instance of StuffService without StuffInstancingBehavior, it's not really optional, so making it configurable doesn't make a whole lot of sense. This means that I should add it programmatically.

To support hosting in as wide a range of scenarios as possible, the best way to ensure that the ServiceHost is always created correctly (even when hosted in IIS) is by implementing a dedicated ServiceHostFactory (let's call it StuffServiceHostFactory). The CreateServiceHost method can be implemented as simply as this:

return new StuffServiceHost(baseAddresses);

Obviously, the real behavior configuration takes place in the StuffServiceHost class, which derives from ServiceHost. The entire implementation takes place in the constructor:

public StuffServiceHost(params Uri[] baseAddresses)

    : base(typeof(StuffService), baseAddresses)

    foreach (ContractDescription cd in

        this.ImplementedContracts.Values)

        cd.Behaviors.Add(new StuffInstancingBehavior());

    this.Description.Behaviors.Find<ServiceBehaviorAttribute>().

        ConcurrencyMode = ConcurrencyMode.Reentrant;

It adds StuffInstancingBehavior to all contracts, which will cause WCF to use its implementation of IInstanceProvider each time it wants to create a new instance of the StuffService. It also modifies the service's ConcurrencyMode; again, why it does that will become apparent in a future post, but I just wanted to show how you can programmatically achieve the same result as decorating your service with the ServiceBehaviorAttribute, since you can't do that directly on StuffService because it's being implemented in a library that doesn't reference WCF.

If you want to host StuffService in IIS, you just need to specify StuffServiceHostFactory in the .svc file's Factory attribute; if you want to host StuffService in your own process, you can just create a new instance of StuffServiceHost directly (or use an instance of StuffServiceHostFactory to create it).

All this behavior modification is taking place without StuffService being aware of it at all, and you can concentrate on implementing the service in whatever way you prefer, while keeping it totally testable and WCF runtime services far away from it. That's a very clean separation of concerns in my book.

Update (2008-07-12): Sample code is available here.

Provider Injection With Funcs

ploeh — Tue, 25 Mar 2008 15:57:00 GMT

Some of the new stuff in .NET 3.5 makes it much easier to implement Provider Injection. If you take a close look at the provider definition, you may discover that when used with Provider Injection, only a single method (Create, or something similarly named) is ever used by the consumer. As such, what we have is essentially an abstraction with only one method (Create). This is true for both ServiceProvider<T> used in my former example, as well as for IServiceProvider.

Allow me to digress for a moment and talk a bit about terminology and how we talk about object-orientation: When I think and talk about object-orientation, I try very hard to stay within the realm of objects. To me, object parameters are passed around as references, not pointers - as far as I'm concerned, a pointer was something I had to deal with when I wrote C++, but it's a low-level detail I don't care to have to deal with anymore. The difference between the words reference and pointer may seem subtle and entirely semantic, but in other cases, the distinction can become much more pronounced.

I've always found it slightly disturbing when people talk about delegates as function pointers. Yes, I admit that the analogy is apparent, but it's not a very object-oriented way to think. To me, a delegate is an anonymous single-method abstraction.

That brings us back to the discussion about service providers, since these are, indeed, single-method abstractions. The implication is that we can model them as delegates. In fact, that has been possible in .NET all along, but until .NET 3.5, the BCL has never offered a good, predefined delegate candidate. In .NET 3.5, however, Func<T> fits the bill perfectly.

If we revisit my previous example, MyClient3 can now be rewritten like so:

public class MyClient3

    private readonly Func<MyServer> create_;

    public MyClient3(Func<MyServer> provider)

        if (provider == null)

            throw new ArgumentNullException("provider");

        this.create_ = provider;

    public string GetServerMessage()

        MyServer server = this.create_();

        return server.DoStuff("ploeh");

This is pure BCL code with no need for complex containers or funky application blocks.

Unit testing MyClient3 is a breeze as well. Assuming that I have an implementation of MyServer that reverses the message, a unit test is as simple as this:

[TestMethod]

public void UseReverseServer()

    MyClient3 mc = new MyClient3(() => new ReverseServer());

    string result = mc.GetServerMessage();

    Assert.AreEqual<string>("heolp", result);

Notice the lambda expression in the MyClient3 constructor.

TechEd Sessions Sample Code

ploeh — Fri, 09 Nov 2007 05:34:00 GMT

Now that both of my TechEd sessions are over, I've had some request for the sample code that I demonstrated at both sessions.

The sample code I used at the interactive talk on TDD is attached to this post.

The code I demonstrated at my talk on manual and dynamic mocks is available upon request. I certainly don't mind sharing it, but for reasons I don't want to go into here, I'm not going to post it for general download, so if you are interested, drop me a line (if you use the Email link on this blog, I'll get an email that also contains your sender address, which means you don't have to publicly post your email address here).

If you didn't go to my sessions, you can still download the sample, but it probably doesn't make as much sense taken out of context.

As usual, the code is provided here "as is", etc.

Speaking at TechEd Developers 2007

ploeh — Wed, 10 Oct 2007 23:04:00 GMT

Again this year, I'll be presenting at TechEd Developers in Barcelona next month. This year, I'll be doing both a general session on mocks, as well an interactive session on TDD. You can read more on these sessions by using the conference's Session Search tool and selecting my name (Mark Seemann) in the Speakers dropdown (it would be easier if there was a direct link to each session, but it doesn't seem like this is the case).

In the general session, I'll be talking about manual and dynamic mocks. If that sounds familiar, it's closely related to my latest MSDN Magazine article. However, I don't intend to simply rehash the material of the article - instead, I plan to drill deeper into the subject of mocks and look at different approaches, so the session will include mostly new content.

Since the chalc talk is an interactive session, I can't really say a lot about what's going to happen, since that will depend on the audience, but I'm sure I'll get some good questions, and I may get to know some intelligent and skilled people along the way.

If you are at TechEd, I hope you'll find it worthwhile to stop by at one of my sessions, or that you'd at least stop me and say hello if you meet me somewhere else at the conference.

User Context

ploeh — Mon, 20 Aug 2007 23:38:00 GMT

Besides logging, one of the most common types of ambient context is the user. Who is the user? Was the user authenticated? What is the user allowed to do?

Since being able to answer these questions are such common requirements in software development, the BCL includes the IPrincipal interface that allows you to create implementations to meet that goal. In many cases, however, you need to know more about your user than just a name, authentication flag and role. You may need separate properties for first and last name, title, the user's age, gender or color preference, contact information, relationships to other users, etc.

Obviously, you can define your own user object that implements IPrincipal and IIdentity while also containing all this extra information. If you do this, here's a couple of design guidelines you should consider:

If you have any sort of volatile dependency in your User object, you should consider making the definition of your class abstract and otherwise abstracting away the dependencies. A simple example concerns the extraction of information. Imagine that you have a database that contains the user's first and last name, as well as a user ID. When you first create the User object, you may only know the user ID, and since you expect that not all callers will ever access the FirstName and LastName properties, you may want to implement lazy loading from the database. However, you should really make those properties abstract, so that other implementations (such as a test double) of your User class can implement different behavior.
If the distinction between IPrincipal and IIdentity doesn't make a lot of sense to you, you can easily let your User class implement both interfaces.
Consider creating a static convenience property for accessing the underlying user-specific store (see the example below).

Let's look at an example illustrating these guidelines. Imagine that you have a need to track and access the user's first and last name, as well as a display name:

public abstract partial class User : IPrincipal, IIdentity
{
    protected User()
    {
    }
 
    public abstract string FirstName { get; }
 
    public abstract string LastName { get; }
 
    public abstract string DisplayName { get; }
 
    // More members...
}

The class is abstract since I want to give inheritors some leeway in how they implement the behavior. In a web application, a derived class may look up the user's properties in a table, perhaps even utilizing lazy loading. An enterprise application may look up the data in Active Directory. A federated service may extract the data from a SAML token. Unit testers will probably want to create a stub or similar.

When implementing IPrincipal and IIdentity, a question that sometimes arises regards the distinction between IPrincipal and IIdentity: Which behavior and data should be implemented where? Should I create both a UserPrincipal and a UserIdentity class? In some cases, it makes sense, while in others, it doesn't. If it doesn't make sense to you in your particular case, you can collapse the implementation of both interfaces into the same class. Notice how in the declaration of the User class, I specified that it implements both IPrincipal and IIdentity. Here's the abstract implementation:

#region IPrincipal Members

public IIdentity Identity

    get { return this; }

public abstract bool IsInRole(string role);

#endregion

#region IIdentity Members

public abstract string AuthenticationType { get; }

public abstract bool IsAuthenticated { get; }

public string Name

    get { return this.DisplayName; }

#endregion

The most tricky aspect is linking the two interfaces to each other via the Identity property, and as you can see, that's dead simple: Just return the object itself. Again, I've cheated a bit since I've just delegated most of the rest of the interface implementation to child classes, but that makes sense, since inheritors may want to implement this functionality in quite different ways: If the backing store is AD, you can basically just wrap WindowsPrincipal and WindowsIdentity. If the backing store is a database, you may want to implement IsInRole with a (cached) stored procedure call. And once more, unit testers will just want to use some sort of test double.

Storing the User object in a user context can obviously be done manually. On Thread.CurrentPrincipal, it's as easy as this:

Thread.CurrentPrincipal = new FakeUser("Jane", "Doe");

Retriving the User instance, on the other hand, requires a bit more code:

User u = Thread.CurrentPrincipal as User;

if (u == null)

    throw new InvalidOperationException("Boo hiss");

// Use u

It's straightforward code, but tedious to have to write over and over again. At this point, many people might be tempted to move this code to a static method on a helper class, but object-oriented design principles recommend that you locate behavior in the class where it belongs - in this case the User class:

public static User Current

get

        /* Possibly use further abstraction here to

         * enable use of HttpContext or similar, as

         * described in previous post. */

        User u = Thread.CurrentPrincipal as User;

        if (u == null)

            // Alternatively use Null Object pattern here.

            throw new InvalidOperationException(

                "CurrentPrincipal is not a User instance.");

        return u;

set

        if (value == null)

            throw new ArgumentNullException("value");

        /* Possibly use further abstraction here to

         * enable use of HttpContext or similar, as

         * described in previous post. */

        Thread.CurrentPrincipal = value;

The static Current property is just a convenience property that encapsulates the behavior described above. In this example, I'm just using Thread.CurrentPrincipal as is, but as described in one of my previous posts, this will not work in ASP.NET. For full flexibility, you could then modify the Current property to use an abstract context container for storing and accessing the IPrincipal instance, as is also described in that post.

In this implementation, I'm also throwing an InvalidOperationException if the current IPrincipal context is not a User instance. One alternative to that would be to return a Null Object, in this case perhaps something like this:

internal class NullUser : User

    internal NullUser()

        : base()

    public override string FirstName

        get { return string.Empty; }

    public override string LastName

        get { return string.Empty; }

    public override string DisplayName

        get { return "Unknown"; }

    public override bool IsInRole(string role)

        return false;

    public override string AuthenticationType

        get { return "Null"; }

    public override bool IsAuthenticated

        get { return false; }

When using a Null Object, however, you should consider whether hiding another IPrincipal instance is the desired behavior. If the current principal is null, it's pretty easy, but it's more difficult to decide on the correct behavior when the current instance implements IPrincipal, but doesn't derive from User. Implicitly suppressing data in this way may lead to logical bugs or unintended behavior, which is why I chose to throw an exception in the above example.

The static Current property provides a convenient and safe way to code against the current user context, since it allows you to write code like this:

string firstName = User.Current.FirstName;

Writing to the User instance is just as easy, if you have writable properties.

A custom User class can evidently be much more complex than the above example, containing complex behavior and relationships to other users, etc. In any case, the general approach outlined here provides a few guidelines for effectively modeling your application's user context.

Call Contexts vs. ASP.NET

ploeh — Sat, 28 Jul 2007 21:56:00 GMT

In my former post on Ambient Contexts, I described how you can use CallContext or Thread Local Storage (TLS) to store a context that is specific to the current context of a call. As it turns out, ASP.NET uses a threading model that disables this approach, since you are not guaranteed that a single request will be entirely executed within a single thread. That's not particularly nice of the ASP.NET platform (to put it politely), but that's the hand we've been dealt. As described by Rockford Lhotka, your first approach should be to use HttpContext.Items when your code runs within a web application, and the CallContext or TLS when outside of ASP.NET.

However, even if you create a wrapper around your storage mechanism, you are still going to carry around a reference to System.Web, which may seem... weird... if you are writing a WPF application or Windows Service or whatever. Besides, this approach is not extensible, since you can't subsequently decide to use yet another context (perhaps you'd want to use WCF's OperationContext). If you've been working with software design for some years, it shouldn't be surprising that the answer is to add yet another level of indirection.

The basic idea is that instead of simply checking whether HttpContext.Current is null or not, you define an abstract context container that can store your custom context in whatever call context is available.

To illustrate this approach, I'll extend my former example to store the context in an abstract container defined by the FeatureContextContainer class:

public abstract class FeatureContextContainer

    protected FeatureContextContainer()

    public abstract FeatureContext Current { get; set; }

Since I don't want to carry around any (potentially) uneccessary references to System.Web or other implementation-specific context implementations, I want to be able to define concrete FeatureContextContainers in my application configuration file (remember that you should also consider including an imperative configuration option). Such a configuration might look something like this:

<configuration>

  <configSections>

    <section name="featureContext"

             type="Ploeh.Samples.FeatureControl.FeatureContextConfigurationSection, Ploeh.Samples.FeatureControl" />

  </configSections>

  <featureContext containerType="Ploeh.Samples.AspNetContext.HttpContextContainer, Ploeh.Samples.AspNetContext" />

</configuration>

In this case, the HttpContextContainer class would implement FeatureContextContainer by reading and writing the context to and from HttpContext.Items. The nice thing about this approach is that while the AspNetContext assembly has a dependency on System.Web, the rest of your application (including FeatureContext itself) doesn't.

The FeatureContext class itself must be modified to use whatever context container is provided to it:

[Serializable]

public abstract class FeatureContext

    private static FeatureContextContainer container_ =

        FeatureContextConfigurationSection.GetConfigurationSection().GetContextContainer();

    protected FeatureContext()

    public static FeatureContext Current

        get { return FeatureContext.container_.Current; }

        set { FeatureContext.container_.Current = value; }

    public abstract void Demand(FeatureLevel requestedLevel);

Instead of directly reading and writing the context to and from the CallContext as before, FeatureContext now delegates these operations to the configured FeatureContextContainer.

While it may seem that this approach now requires an application configuration file, this is actually not the case, since I implement FeatureContextConfigurationSection.GetConfigurationSection in this way:

public static FeatureContextConfigurationSection GetConfigurationSection()

    FeatureContextConfigurationSection config =

        ConfigurationManager.GetSection(

        FeatureContextConfigurationSection.ConfigurationName)

        as FeatureContextConfigurationSection;

    if (config != null)

        return config;

    return new DefaultFeatureContextConfigurationSection();

Notice that if the configuration section isn't found in the application configuration file (or if no such file exists at all), I return a DefaultFeatureContextConfigurationSection instead. This internal class simply overrides the virtual GetContextContainer method:

internal class DefaultFeatureContextConfigurationSection :

    FeatureContextConfigurationSection

    internal DefaultFeatureContextConfigurationSection()

        : base()

    public override FeatureContextContainer GetContextContainer()

        return new CallContextContainer();

Instead of using a configured type name to create an instance of that type, this implementation simply returns an instance of the CallContextContainer class:

internal class CallContextContainer : FeatureContextContainer

    private const string contextSlotName_ = "FeatureContext";

    internal CallContextContainer()

        : base()

    public override FeatureContext Current

get

            FeatureContext ctx = CallContext.LogicalGetData(

                CallContextContainer.contextSlotName_) as FeatureContext;

            if (ctx == null)

                ctx = new BasicContext();

                CallContext.LogicalSetData(

                    CallContextContainer.contextSlotName_, ctx);

            return ctx;

set

            CallContext.LogicalSetData(

                CallContextContainer.contextSlotName_, value);

If you recall the code from my former post, this is simply the original implementation of FeatureContext moved to a FeatureContextContainer implementation. By this, we have now come full circle: The default behavior of FeatureContextContainer is the same as described in my former post, and I have introduced no breaking changes, but now the implementation is extensible, which allows you to reuse this ambient context in an ASP.NET application.

In a unit testing scenario, CallContext works just fine, so you don't need to replace the default implementation in that case. This means that even if you would want to use FeatureContext in an ASP.NET application, you'd still write all your unit tests against the default implementation, and then, when you configure the entire application, you set it up with an HttpContextContainer. The HttpContextContainer class, on the other hand, is one of those software infrastructure types that you can't unit test, so if you really want to test it, you will need an integration test. On the other hand, the implementation is so simple that this will probably not be necessary.

Ambient Context

ploeh — Tue, 24 Jul 2007 00:06:00 GMT

These days, I'm becoming increasingly enamored with the idea of implementing cross-cutting concerns using Thread Local Storage (TLS) or the current call context. For the most typical aspects of software, such as security and logging, the .NET framework already takes this approach:

Security can be handled by reading or writing to Thread.CurrentPrincipal
Logging can be handled by using the methods of the Trace class. You configure the Trace class by adding or removing TraceListerners.

In both cases, you set up the context at the application's entry point (either imperatively or, in the case of logging, in the application's configuration), which makes it implicitly available for all other code in the call stack. Even if you are writing code in the data access layer (which is usually quite deep in the call stack), you can still access and use this ambient context. The nice thing about this approach is that it's just there, accessible by a static property or method on a well-defined class (i.e. Thread or Trace). This means that even though you might need to be able to address your cross-cutting concern in any layer in your application, you don't need to pass it around as a parameter value in every single method you implement.

Even though it's not passed to you explicitly as a parameter, you are allowed to assume that it's there; it's the responsibility of the hosting application to set up the ambient context in the correct way.

Since both IPrincipal and TraceListener are abstractions (one is an interface and the other an abstract class), these implementations offer full substitutability, so you can easily create test doubles of them when unit testing.

Obviously, you can just use Thread.CurrentPrincipal and the Trace class for security and logging, but if you have your own aspect to implement, you can use a similar approach. As always, I prefer to illustrate how to do this with an example. In order to avoid the usual suspects of security and logging, consider the following scenario:

We are building an application where you need to be able to control which features are available to the user at any given time. This is not a question of role-based security, but rather a decision which may be made based on licensing etc. One scenario may be a trial edition with certain features disabled (but where you can upgrade the installation to a full version without reinstalling). A more advanced scenario may be a SmartClient application (perhaps in a SaaS scenario) where the user can pay to upgrade the application's feature level for a limited time.

To keep things simple, we'll assume that we only need three levels of feature access:

public enum FeatureLevel

    Basic = 0,

    Silver,

    Gold

Since we must allow developers to create an implementation where a level of access is only available for a limited time, the API should allow a great deal of flexibility. With the pseudo-requirements set forth so far, our goal could be to enable our fellow developers to write code akin to this:

FeatureContext.Current.Demand(FeatureLevel.Silver);

The Demand method simply asserts that the requested feature level is currently enabled, and otherwise throws an exception. The FeatureContext class in itself is an abstract class:

[Serializable]

public abstract class FeatureContext

    private const string contextSlotName_ = "FeatureContext";

    protected FeatureContext()

    public static FeatureContext Current

get

            FeatureContext ctx = CallContext.LogicalGetData(

                FeatureContext.contextSlotName_) as FeatureContext;

            if (ctx == null)

                ctx = new BasicContext();

                CallContext.LogicalSetData(

                    FeatureContext.contextSlotName_, ctx);

            return ctx;

set

            CallContext.LogicalSetData(

                FeatureContext.contextSlotName_, value);

    public abstract void Demand(FeatureLevel requestedLevel);

There are two noteworthy details in this code: The first is the abstract Demand method that needs to be implemented by a derived class (I'll get back to that).

The second is the static Current property. Since it allows any client to read and write an instance of the abstract FeatureContext, substitutability is ensured. It also ensures that you can implement the Demand method in as simple or complex fashion as you need, and put this implementation on the ambient context. To keep things simple, I've not implemented the property in a thread-safe manner, which (obviously) you should do in a real production implementation.

In this implementation, I store the the FeatureContext in the CallContext; I could also have used TLS by using Thread.SetData, but there's a difference: Using TLS, the context only exists on the current thread; if you spawn a new thread, you must manually copy the context to the new thread if you want it to be available there as well. This happens automatically when you use the CallContext, but to store and retrieve an object via the CallContext, the class must be serializable, which is why FeatureContext is decorated with the Serializable attribute. Any derived class must also be serializable.

If no current context is not already set, it defaults to BasicContext:

[Serializable]

public class BasicContext : FeatureContext

    public BasicContext()

        : base()

    public override void Demand(FeatureLevel requestedLevel)

        if (requestedLevel > FeatureLevel.Basic)

            throw new FeatureUseDeniedException();

This implementation only allows basic functionality. If the requested feature level is higher than Basic, a FeatureUseDeniedException is thrown. Notice the Serializable attribute, which allows an instance of the class to be stored in the CallContext.

You can implement SilverContext and GoldContext classes in similar ways, so when you want to enable Gold functionality indefinitely, you'd do something like this:

FeatureContext.Current = new GoldContext();

This will enable Gold funtionality until you explicitly change the FeatureContext to something else. If you want to enable a scenario where there's a time limit, you could create an expiring implementation of FeatureContext:

[Serializable]

public class ExpiringGoldContext : FeatureContext

    private DateTime timeLimit_;

    public ExpiringGoldContext(TimeSpan allottedTime)

        : base()

        this.timeLimit_ = DateTime.Now + allottedTime;

    public override void Demand(FeatureLevel requestedLevel)

        if (DateTime.Now > this.timeLimit_)

            new BasicContext().Demand(requestedLevel);

            return;

        new GoldContext().Demand(requestedLevel);

When you set the current FeatureContext to ExpiringGoldContext, it will allow Gold features to be used until the time limit expires. Even when the time limit expires, the current instance remains, but its behavior changes to only allow Basic functionality. Obviously, you could optimize the implementation of ExpiringGoldContext by defining static readonly instances of BasicContext and GoldContext, but to keep things simple for the example, I just create new instances of these classes when I want to delegate implementation to them.

Whenever your need to ensure that a member allows execution only if a certain functionality level is granted, you can demand the level as a guard clause in your code:

public void DoSilverStuff()

    FeatureContext.Current.Demand(FeatureLevel.Silver);

    // Implementation here

To come full circle to aspect-oriented development, such a use of ambient context is an obvious candidate for the Enterprise Library Policy Injection Application Block, which would then allow declarative use of the ambient context by decorating your members with attributes (similar to PrincipalPermissionAttribute), but I'll leave that as an exercise for the interested reader (or, perhaps, a later post).

State Your Dependency Intent

ploeh — Sun, 03 Jun 2007 00:11:00 GMT

There are several different ways to implement Dependency Injection (DI), and Martin Fowler describes four of them in his excellent article on IoC/DI. In this article, the first three approaches (Constructor, Property, and Interface Injection) are mainly described as a background for introducing the Service Locator pattern. In Fowler's example, a generic Service Locator is a registry (basically an in-memory table), but these days you most commonly see it implemented as a factory.

Consider this simple interface:

public interface IMyInterface

    void DoStuff();

Here's a class that uses a Service Locator to get an instance of IMyInterface:

public class ImplicitConsumer

    public void PerformOperation()

        IMyInterface mi = ServiceFactory.Create<IMyInterface>();

        mi.DoStuff();

The ServiceFactory class has a static method that returns an instance of the requested interface. Although not explicitly shown, the ImplicitConsumer class has a default constructor, since no constructor is defined and the C# compiler then automatically creates one.

Now, imagine yourself in a situation where you need to consume an instance of the ImplicitConsumer class and call its PerformOperation method. Also imagine that you have just been handed the class in a binary form, with documentation, but without source code. In this scenario, you would probably write code like this:

ImplicitConsumer ic = new ImplicitConsumer();

ic.PerformOperation();

Writing the first line is very straightforward, since there's only one way to create a new instance of the class. Next, with the ic instance, IntelliSense will quickly help you to find and invoke the PerformOperation method, and that's it: The code compiles and you are happy.

At run-time, however, this code is going to fail, since the Service Locator has not been configured. At this point, you may resort to the documentation, and if you are lucky, the documentation will tell you that the PerformOperation method expects the Service Locator to be configured to return an instance of IMyInterface. If you aren't so lucky, you will have to fire up Reflector to figure out what to do.

Depending on the Service Locator's implementation, this configuration may be done in the configuration file or in code. Here's how it might look in code:

ServiceFactory.Preset<IMyInterface>(new StubMyInterface());

ImplicitConsumer ic = new ImplicitConsumer();

ic.PerformOperation();

Here we have what looks like two pieces of totally unrelated code, yet they are very closely related at run-time. If you came by this code without prior knowledge, you'd probably mistake the first line of code for a piece of lava flow and delete it. If you were the author of those three lines, you might attempt to protect yourself from this risk by applying a comment to the first line, but that would be an apology.

In my opinion, an API should always strive to steer developers in the right direction. With respect to DI, the API should clearly state its intent to consume a particular dependency. Constructor Injection does this very explicitly:

public class ExplicitConsumer

    private IMyInterface mi_;

    public ExplicitConsumer(IMyInterface mi)

        if (mi == null)

            throw new ArgumentNullException("mi");

        this.mi_ = mi;

    public void PerformOperation()

        this.mi_.DoStuff();

With this implementation, any developer is forced to do the right thing. There's only a single constructor, and IntelliSense will show that it expects an instance of IMyInterface. While a developer could pass null as a parameter, he or she would do so in spite of the knowledge that was just communicated by IntelliSense (and there would still be a run-time error). There would be no need to read the documentation or fire up Reflector, because the class makes it very clear that it needs a working instance of IMyInterface to perform its work, and as a developer, you must supply it:

ExplicitConsumer ec =

    new ExplicitConsumer(new StubMyInterface());

ec.PerformOperation();

The only drawback of Constructor Injection that I have ever been able to identify is the need to initialize all dependencies at once if you have a complex hierarchy of dependencies, as described in my former post. If lazy initialization is a necessity, you can use Provider Injection, which is a variation of Constructor Injection. Although this is currently my favorite DI strategy, it's less well-known and more difficult to explain.

In any case, the main point is that if a component expects to consume a dependency which will be supplied at run-time, it should clearly state that intent through its API, instead of relying on out-of-band discovery mechanisms. Although the API may end up looking more complex, it's ensuring that mistakes are much harder to make. Even if there's a slightly more pronounced learning curve to get started with an API that uses Constructor Injection, it's easier to use in the long run. A developer with no prior knowledge of the component will sooner be able to produce code that compiles with a component relying on a Service Locator, but he or she will sooner be able to produce code that works with Constructor Injection.

Code As Dependency Configuration

ploeh — Wed, 30 May 2007 17:33:00 GMT

In his article on Inversion of Control and Dependency Injection, Martin Fowler has a quite interesting section towards the end where he talks about how to configure loosely coupled systems. One of his points is that in some cases, it makes more sense to tie it all together using code than by using a configuration system.

When I introduce the concept of Code As Configuration for most people, they seem to instantly stop listening to what I'm saying. Configuration (the ability to change the behavior of the application without changing its code base) is good, so why would you ever want not to enable configuration? In .NET, this notion is particularly strong because System.Configuration makes it so easy to create a rich configuration object model backed by XML configuration files.

With Dependency Injection, the configurable entities are types (defined in various assemblies). Because of Dependency Injection, each library in your application can be compiled in isolation, since its volatile dependencies are being injected at run-time. A design pattern such as Constructor Injection is fairly simple and intuitive to use as long as you use it in isolation during development (e.g. while unit testing), but when it comes to tying everything together in an executable application, all these dependencies must be loaded into an object hierarchy such as this one:

In this example, each class is defined in a separate assembly. Note that the arrows indicate usage, not dependencies. For the application to run in the desired configuration, ClassC must consume an instance of ClassE, and so forth. However, ClassC only knows about Abstraction5, which is being injected into it via its constructor:

public class ClassC : Abstraction3

    private Abstraction5 a5_;

    public ClassC(Abstraction5 a5)

        : base()

        this.a5_ = a5;

    protected override string DoStuffCore()

        StringBuilder builder = new StringBuilder();

        builder.AppendLine("I am really Class C. My dependency says:");

        builder.Append(this.a5_.DoStuff());

        return builder.ToString();

The other classes are implemented in a similar way; ClassB, for example, only communicates with Abstraction3 and Abstraction4 and doesn't have any knowledge of ClassD or ClassC (let alone that in this configuration, ClassC consumes ClassE).

The executable must somehow construct the correct object graph. A common approach is to use the app.config file to define this hierarchy (for an example, Spring.NET supports this option). To properly identify which type to instantiate when an abstraction is requested, an assembly-qualified type name is provided in the configuration file, and reflection is used to create instances of the configured types.

This very common approach comes with a rather painful drawback: Since the executable application has no dependencies on any of its servers, none of the containing assemblies are automatically copied to the output directory. Although the application compiles, it crashes when executed because Fusion is unable to locate the assemblies specified in the configuration file.

To work around this, you can either put all of your assemblies in the GAC or copy them to the relevant output directory, but both of these options are either repetitive or requires automation. In any case, this drawback can be a bit counter-productive during development.

Another approach is simply to code the desired configuration into the top-level executable. Whether this is a viable option depends on your reason for isolating your volatile dependencies in the first place. If your motivation is genuinely to support plug-ins or other extensibility models, configuration-driven Dependency Injection is certainly the right approach, and hard-coding a particular configuration is not an option. For other scenarios, however, this solves the problem of managing and deploying the correct assemblies.

In my example, the client will create the entire object hierarchy like this:

static void Main(string[] args)

    Abstraction1 a1 = Program.CreateAbstraction1();

    Abstraction2 a2 = Program.CreateAbstraction2();

    Console.WriteLine(a1.DoStuff());

    Console.WriteLine(a2.DoStuff());

    Console.ReadKey(true);

private static Abstraction1 CreateAbstraction1()

    return new ClassA();

private static Abstraction2 CreateAbstraction2()

    Abstraction5 a5 = new ClassE();

    Abstraction4 a4 = new ClassD();

    Abstraction3 a3 = new ClassC(a5);

    Abstraction2 a2 = new ClassB(a3, a4);

    return a2;

Since all implementations use Constructor Injection, the client can construct the entire object tree by starting with the leaves and working its way to the root of the tree. Notice that although this creates an object hierarchy as illustrated above, the dependency hierarchy is flattened:

Apart from the top-level executable, each assembly only has a dependency on an assembly containing the abstractions (base classes and interfaces). Since such an assembly is considered a stable dependency, isolation has been achieved for all libraries. The only assembly with volatile dependencies is the top-level executable, but that's commonly where your UI resides, so it's not going to be testable in any case (and should be kept as minimal as possible).

Since the top-level executable has all relevant dependencies for the desired configuration, all required assemblies will automatically be part of the build.

Obviously, if you ever need to run the application in a different configuration, you will need to change the code, compile and redeploy, but that's not particularly different from the pure configuration scenario. Even if you use a configuration file, you will still need to compile and deploy your new or changed modules. In my opionion, it's the overhead of actually deploying even a single file that carries the greatest cost; whether you copy one or all of your files is merely a question of network or disk transfer time.

For applications where you control the entire code base and no extensibility support is required, the Code As Configuration technique can make development teams more productive without sacrificing significant functionality.

Testing Against The Passage of Time

ploeh — Mon, 14 May 2007 20:08:00 GMT

This is the fourth in a small series of posts about testing against non-determinism. In this installation, I'm going to cover the passage of time.

In my former post, I demonstrated how you can use the Provider Injection pattern to decouple your test target from a direct dependency of the current system time. In unit tests, the DateTime provider will serve up whatever value is defined by the test developer, while in production, the provider will serve up the real system time.

You can use this ability to control the apparent system time to greatly speed up time-dependent code. Although I must admit that it's not everyday that I write code that must execute for a particular length of time, I have run into this scenario from time to time, and each time I've used this principle to accelerate time during testing.

Consider this simple example:

public void DoSomeWaiting()

    TimeSpan waitTime = TimeSpan.FromSeconds(30);

    DateTime initialTime = DateTime.Now;

    while (DateTime.Now < initialTime.Add(waitTime))

        Thread.Sleep(TimeSpan.FromMilliseconds(10));

In a real-life situation, you will probably have a reason for doing something like this, but the main point is that this method simply blocks for 30 seconds before it returns. Since every invocation of DoSomeWaiting takes 30 seconds, this method is a pain to unit test - particularly if you are using test-driven development (TDD). Each unit test will take at least 30 seconds, and if you have a suite of tests, you can multiply this period with the number of tests involving this method. Such a suite may easily take several minutes to execute.

For an automated build verification test, this may not be a big deal, but in TDD this is disastrous, since it totally destroys the fast-paced code-compile-test development cycle.

To amend this problem, you can alter the implementation of the method. If I add the method to the TimeConsumer class from my former post, I can implement it in this way:

public void DoSomeWaiting()

    TimeSpan waitTime = TimeSpan.FromSeconds(30);

    DateTime initialTime = this.dateTimeProvider_.Create("Now");

    while (this.dateTimeProvider_.Create("Now") < initialTime.Add(waitTime))

        Thread.Sleep(TimeSpan.FromMilliseconds(10));

Instead of using DateTime.Now, I use an externally supplied ServiceProvider<DateTime> to get the 'current time' (as usual, I should point out that although I use Service Locator 2, you can also apply the principle in other ways, for example with IServiceProvider implementations).

With this implementation, I can now write a unit test that will execute orders of magnitude faster:

[TestMethod]

public void PerformAcceleratedWait()

    ServiceProvider<DateTime> dateTimeProvider =

        new ServiceProvider<DateTime>();

    dateTimeProvider.Preset(new DateTime(2007, 5, 7), "Now");

    TimeConsumer tc = new TimeConsumer(dateTimeProvider);

    Stopwatch watch = new Stopwatch();

    watch.Start();

    ThreadPool.QueueUserWorkItem(delegate(object state)

        Thread.Sleep(TimeSpan.FromMilliseconds(10));

        dateTimeProvider.Preset(new DateTime(2007, 5, 7, 0, 0, 31), "Now");

});

    tc.DoSomeWaiting();

    watch.Stop();

    Assert.IsTrue(watch.Elapsed < TimeSpan.FromSeconds(30));

Instead of having to wait for 30 seconds, this unit test executes much faster: On my system, watch.Elapsed tends to be slightly higher than 10 ms!

Being able to run a suite of tests where you can compress arbitrary periods of time down to almost no time is a great addition to your tool belt. If you are curious about this technique, I used it quite extensively for the StarShip quickstart for Service Locator 2. In those tests, I typically compress hours into a few milliseconds of test time, so it sure saved me a lot of time.

Testing Against The Current Time

ploeh — Sat, 12 May 2007 21:45:00 GMT

This is the third in a small series of posts about testing against non-determinism. In this installation, I'm going to cover how to deal with the current time or date.

If you have logic that is dependent of the current time or date, test results will vary according to the time you run your tests. As always, my examples tend toward the overly simplistic, but consider this method:

public bool IsTodayAWeekDay()

    DateTime now = DateTime.Now;

    if ((now.DayOfWeek == DayOfWeek.Saturday) ||

        (now.DayOfWeek == DayOfWeek.Sunday))

        return false;

    return true;

The main point of this example is that the code braches on the value of DateTime.Now. Obviously, if you execute a test against this method on a weekday, the method will return true, but otherwise it will return false.

[TestMethod]

public void UseNonDeterministicTimeConsumer()

    NonDeterministicTimeConsumer tc = new NonDeterministicTimeConsumer();

    bool result = tc.IsTodayAWeekDay();

    // How to verify result?

As you can see, you can't really test this method. A quick fix for this could be to change the method's signature to accept the current time as a parameter, but this may not be a good idea for a number of reasons (which I'll leave as an exercise for the interested reader).

If changing the method's signature is not an option, then how can you test such a method?

This is a case where the Provider Injection pattern really comes into its own. Unlike other Inversion of Control patterns, Provider Injection can delay the creation of a dependency until it is needed. Since the current time is continually changing, you should never request an instance before you need it, and that's exactly what you can do with Provider Injection.

As always, I'm using Service Locator 2's ServiceProvider<T>, but you can always use an implementation of IServiceProvider and do a bit of casting if you want to stick to the BCL proper.

public partial class TimeConsumer
{
    private ServiceProvider<DateTime> dateTimeProvider_;
 
    public TimeConsumer(ServiceProvider<DateTime> dateTimeProvider)
    {
        this.dateTimeProvider_ = dateTimeProvider;
    }
 
    public bool IsTodayAWeekDay()
    {
        DateTime now = this.dateTimeProvider_.Create("Now");
 
        if ((now.DayOfWeek == DayOfWeek.Saturday) ||
            (now.DayOfWeek == DayOfWeek.Sunday))
        {
            return false;
        }
 
        return true;
    }
}

The trick is to defer creation of the DateTime instance until you need it. Incidentally, you see here a rather nice feature of Service Locator 2 illustrated: Requesting a DateTime instance named "Now" allows Service Locator to distinguish between several requested DateTime objects (you might also want to be able to create what corresponds to DateTime.Today), but it also allows Service Locator to infer the correct creation strategy for the requested instance. This means that unless you intercept it by presetting or configuring a value, ServiceProvider<DateTime> will simply use DateTime.Now.

In the test, however, you do want to intercept the default strategy by presetting the current time to a predefined value:

[TestMethod]

public void CheckMonday()

    ServiceProvider<DateTime> dateTimeProvider =

        new ServiceProvider<DateTime>();

    // 2007-05-07 is a Monday

    dateTimeProvider.Preset(new DateTime(2007, 5, 7), "Now");

    TimeConsumer tc = new TimeConsumer(dateTimeProvider);

    Assert.IsTrue(tc.IsTodayAWeekDay());

When executed, the Create method will always return the preset instance - in this case alway May 7th, 2007, which is a Monday. Obviously, you can write similar tests for the other days of the week.

Next: Testing Against The Passage of Time

Testing Against Randomness

ploeh — Fri, 11 May 2007 22:21:00 GMT

This is the first in a small series of posts about testing against non-determinism. In this installation, I'm going to cover randomness.

When code paths are selected at random, the outcome of a unit test may not be deterministic. Consider this example:

public bool DoRandomStuff()

    Random r = new Random();

    if (r.NextDouble() < .5)

        return false;

    return true;

This method has a fifty percent chance of returning either true or false, but you if you write a unit test, you will not be able to tell what the result will be in advance. In this very simplified case it may not be of much consequence, but if you have more complex logic, you will want to be able to test any possible code path and their return values, and you can't do that if a part of the code path is determined by uncontrolled randomness.

The key is obviously to inject controlled randomness. With the Random class, this is actually fairly easy, since it provides an overloaded constructor that takes a seed, and as you probably know, the sequence of random numbers generated is always the same for the same seed, and hence, deterministic.

This doesn't help a lot unless you feed either the seed or the entire Random instance into your class from the outside. I personally prefer to inject the entire Random instance, since that seems more natural: It clearly signifies to the caller that randomness may happen in this class; at least more clearly than some integer seed. You can choose to pass the Random instance to the class as a whole, or just pass it as a parameter to a single method. In this example, I'm using Construtor Injection to pass it to the class in its entirety, since that doesn't break the signature of the DoRandomStuff method:

public class RandomConsumer

    private Random random_;

    public RandomConsumer(Random r)

        this.random_ = r;

    public bool DoRandomStuff()

        if (this.random_.NextDouble() < .5)

            return false;

        return true;

As you can tell, I'm just populating the class with an already created instance of Random, and I use that instance to get my random numbers. From a unit test, I can then test the method like this:

[TestMethod]

public void GetTrue()

    RandomConsumer rc = new RandomConsumer(new Random(0));

    Assert.IsTrue(rc.DoRandomStuff());

A seed value of 0 causes NextDouble to return approximately 0.7, which causes the DoRandomStuff method to return true. A seed of 1 will cause NextDouble to return approximately 0.2, which will result in false, so you can write a test similar to the one above with a seed of 1 and test that the return value is false.

While you would inject a seeded Random into the class from a unit test, you would obviously use it with an unseeded Random in production code to introduce true(r) randomness:

RandomConsumer rc = new RandomConsumer(new Random());

Note that in this example, I've used the Constructor Injection pattern to keep things simple. However, as I wrote in my post about Provider Injection, this has the disadvantage of requiring early initialization of the Random instance, even if it's not going to be used right away. In real production code, I'd typically used Provider Injection and pass a provider that can create Random instances when I need them; thus allowing for lazy initialization.

Next: Testing Against Guids

Provider Injection

ploeh — Sun, 25 Mar 2007 21:41:00 GMT

In his article Inversion of Control Containers and the Dependency Injection pattern, Martin Fowler describes four types of inversion of control:

Constructor Injection
Property Injection
Interface Injection
Service Locator

Constructor injection and service locator are, in my opinion, the most attractive patterns for addressing the challenge of configuring a component's servers in a flexible manner. They both have advantages and disadvantages, but a third way exists, which I call provider injection.

As usual, a simplistic example will serve to illustrate my points. Assume that you need to use this server in a client:

public abstract class MyServer

    protected MyServer()

    public abstract string DoStuff(string message);

Using the constructor injection pattern, a client might look like this:

public class MyClient1

    private MyServer server_;

    public MyClient1(MyServer server)

        if (server == null)

            throw new ArgumentNullException("server");

        this.server_ = server;

    public string GetServerMessage()

        return this.server_.DoStuff("ploeh");

This approach is robust and easy to understand. It does, however, also come with a disadvantage: A client of MyClass1 must always supply the required dependency. For a class which will always use the dependency heavily, this may not be a problem, but if the dependency is only used in specialized situations, this may incur an initialization overhead. If you have an entire hierarchy of clients and services, using this pattern requires you to initialize all dependencies immediately, which may lead to increased start-up time.

The serivce locator pattern is typically implemented by using a registry that can be queried for dependencies; often in the form of a factory class. An client utilizing this pattern might look like this:

public class MyClient2

    public MyClient2()

    public string GetServerMessage()

        MyServer server = ServiceFactory.Create<MyServer>();

        return server.DoStuff("ploeh");

(I'm using Service Locator 2 here, but other lightweight container frameworks such as Spring.NET work in essentially the same way.)

Contrary to constructor injection, this implementation doesn't suffer from the early initialization problem: If the first call to GetServerMessage occurs five minutes into the application's lifetime, the MyServer instance will not be created before then. In other words, this pattern supports Just-in-Time (JiT) initialization of dependencies.

On the other hand, the usability of MyClient2 is not nearly as good as MyClient1. In the first example, any caller of MyClient1 must supply the dependency. The API communicates very clearly what you must do to use the class. On the other hand, you could easily write code utilizing MyClient2 like this:

MyClient2 mc = new MyClient2();

string result = mc.GetServerMessage();

This code snippet will compile, but you will get a run-time error if ServiceFactory can't create the requested instance, which may very well be the case. To make the application work, it's neccessary to configure the service locator (in this case ServiceFactory) either by app.config files or somewhere else in the code. Although configuration-driven applications may be desirable for a lot of reasons, it doesn't make usability of the API better. If you forget to configure the service locator, you will have to resort to the documentation to figure out what to do, since the API itself offers no help in this regard.

Provider Injection attempts to achieve the best of both worlds:

Enabling API design that clearly communicates dependency requirements
Enabling JiT initialization of dependencies

Here's an example of a class utilizing provider injection:

public class MyClient3

    private ServiceProvider<MyServer> provider_;

    public MyClient3(ServiceProvider<MyServer> provider)

        if (provider == null)

            throw new ArgumentNullException("provider");

        this.provider_ = provider;

    public string GetServerMessage()

        MyServer server = this.provider_.Create();

        return server.DoStuff("ploeh");

(Again, I'm using Service Locator 2 as my example, but instead of ServiceProvider<T>, you could use System.IServiceProvider or some other, similar type.)

Using the provider injection pattern, the provider must be supplied by any caller of MyClient3, but the dependency itself isn't created before it is needed. The API is still rather explicit about its expectations, since it requres you to supply the provider, so it leaves less room for error.

A variant of this pattern is to require the provider as an input parameter to a method. A lot of classes in the .NET framework uses this approach, particularly in the design-time framework (System.ComponentModel.Design namespace).

If you are interested in a less simplistic implementation using this approach, you can take a look at the StarShip QuickStart sample in the Service Locator 2 application block, which creates a complex hierarchy of dependencies.