Espresso Fueled Agile Development : Example Driven Design (Formerly TDD)

Unit testing SharePoint

mpuleio — Sat, 23 Aug 2008 00:38:00 GMT

Francis has an article on Unit Testing SharePoint 2007 Applications

He also did a brownbag talk on this yesterday, which was very interesting and brought up a few big challenges and ways to work around them.

Enjoy

Converting the Composite Web Application Block to Unity - Actually Adding Unity

mpuleio — Fri, 02 May 2008 02:44:34 GMT

This is the fifth post in a series. The other post include:

If you want background, go read the earlier posts.

Based upon feedback, I am making the source code available at CWAB and Unity.

First off, I have moved this little side project to source control, so I can avoid the re-work I had to do before I could write this part of the series.

Note to self :

NEVER work without a safety net. That means both unit tests and source control.

Ok. Now that that is out of the way....

Let's go add Unity to CWAB, via EDD (formerly TDD).

How can we do this? First, we need a test fixture. So, I added CompositionContainerFixture to the CompositeWeb.Tests project as an empty test fixture. And then I added the following very simple test as a starting point:

[TestMethod]
public void UnityCompositionContainerIsICompositionContainer()
{
    UnityCompositionContainer container = new UnityCompositionContainer();
    Assert.IsInstanceOfType(container, typeof(ICompositionContainer));
}

This will allow me to write enough code to create the UnityCompositionContainer class and ensure that it implements the right interface.

Making the test compile forces me to create a new UnityCompositionContainer class (I added it to the fixture as a nested class for the moment), and the test fails. No problem. I add the interface, implement it with methods that throw, and..... We are green again.

Next step, I copied the unit test RootContainerParentIsNull over, changed its name to NewUnityContainerParentIsNull, updated it to create a new UnityCompositionContainer, and compiled and ran the test. It passed, which is not idea;l, but I will leave it an move on, knowing it will be important later. For the next test, I copied ChildContainerHasParent changed its name to NewUnityContainerParentIsNull, updated it to create a new UnityCompositionContainer, and compiled and ran the test... Red. Just like we expected. To make this work, I could do a bit of throw away work, or I could add Unity. I feel like I can skip the simplest thing possible, because I know where I want to go.

However, first, I'm doing a check-in. I'll comment out the failing test, and sync up. Just a sec.

Ok, now To add Unity. I grabbed the binaries from MSDN, dropped them in my tree in the Lib folder and we are good to go. I added references in the CWAB projecct to Unity.DLL and ObjectBuilder2.DLL. This means we have two completely separate DI systems as part of out code, which is awful. However, it won't last too long.

Now, we can make that test pass. I added an IUnityContainer field to UnityCompositionContainer. I then implemented a constructor to initialize it. Then we needed to implement CreateChildContainer. For this, the simplest thing was to create a new constructor for UnityCompositionContainer which takes a parent container as the only parameter. After a little wire-up we end up with passing tests and this code:

private UnityCompositionContainer(UnityCompositionContainer parentContainer)
{
    Parent = parentContainer;
    wrappedContainer = parentContainer.wrappedContainer.CreateChildContainer();
}

public ICompositionContainer CreateChildContainer()
{
    UnityCompositionContainer child = new UnityCompositionContainer(this);
    return child;
}

Fairly simple. I will continue moving unit tests over, adapting them, and making them pass. If there are any interesting deviations from normal, or new tests added, I'll let you know.

That was actually fairly simple. I copied the tests one at a time, replaced the container used with the UnityCompositionContainer, compiled, ran the tests, watched them fail due to NotImplementedExceptions, and fixed them. Here's the test fixture:

[TestClass]
public class UnityCompositionContainerFixture
{
    [TestMethod]
    public void UnityCompositionContainerIsICompositionContainer()
    {
        UnityCompositionContainer container = new UnityCompositionContainer();
        Assert.IsInstanceOfType(container, typeof (ICompositionContainer));
    }

    [TestMethod]
    public void NewUnityContainerParentIsNull()
    {
        ICompositionContainer container = new UnityCompositionContainer();
        Assert.IsNull(container.Parent);
    }

    [TestMethod]
    public void ChildContainerHasParent()
    {
        ICompositionContainer parent = new UnityCompositionContainer();

        ICompositionContainer child = parent.CreateChildContainer();

        Assert.AreSame(parent, child.Parent);
    }

    [TestMethod]
    public void CanRegisterTypeMappingOnRootContainer()
    {
        UnityCompositionContainer root = new UnityCompositionContainer();

        root.RegisterType<IFoo, Foo>();

        IFoo resolvedIFoo = root.Resolve<IFoo>();

        Assert.AreEqual(typeof (Foo), resolvedIFoo.GetType());
    }

    [TestMethod]
    public void CanRegisterTypeMappingViaTypeObjects()
    {
        UnityCompositionContainer root = new UnityCompositionContainer();
        root.RegisterType(typeof (IFoo), typeof (Foo));

        IFoo resolvedIFoo = root.Resolve<IFoo>();

        Assert.AreEqual(typeof (Foo), resolvedIFoo.GetType());
    }

    [TestMethod]
    public void RequestingTypeMappingForUnmappedTypeReturnsRequestedType()
    {
        UnityCompositionContainer root = new UnityCompositionContainer();

        Foo resolvedFoo = root.Resolve<Foo>();

        Assert.AreEqual(typeof (Foo), resolvedFoo.GetType());
    }

    [TestMethod]
    [ExpectedException(typeof (ArgumentException))]
    public void TypeMappingsMustBeTypeCompatible()
    {
        UnityCompositionContainer root = new UnityCompositionContainer();
        root.RegisterType(typeof (IBar), typeof (Foo));
    }

    [TestMethod]
    public void CanRegisterMultipleTypeMappings()
    {
        UnityCompositionContainer root = new UnityCompositionContainer();

        root.RegisterType<IFoo, Foo>();
        root.RegisterType<IBar, Bar>();
        IBar b = root.Resolve<IBar>();
        IFoo f = root.Resolve<IFoo>();

        Assert.AreEqual(typeof (Bar), b.GetType());
        Assert.AreEqual(typeof (Foo), f.GetType());
    }

    [TestMethod]
    public void RequestingTypeMappingOnChildReadsFromParent()
    {
        UnityCompositionContainer parent = new UnityCompositionContainer();
        ICompositionContainer child = (ICompositionContainer) parent.CreateChildContainer();

        parent.RegisterType<IFoo, Foo>();

        Assert.AreEqual(typeof (Foo), child.Resolve<IFoo>().GetType());
    }

    [TestMethod]
    public void ChildContainersCanOverrideParentTypeMapping()
    {
        UnityCompositionContainer parent = new UnityCompositionContainer();
        ICompositionContainer child = (UnityCompositionContainer) parent.CreateChildContainer();

        parent.RegisterType<IFoo, Foo>();
        child.RegisterType<IFoo, Foo2>();

        Assert.AreEqual(typeof (Foo), parent.Resolve<IFoo>().GetType());
        Assert.AreEqual(typeof (Foo2), child.Resolve<IFoo>().GetType());
    }

    [TestMethod]
    public void CanCreateChildContainer()
    {
        ICompositionContainer container = new UnityCompositionContainer();

        ICompositionContainer child = container.CreateChildContainer();
        Assert.IsNotNull(child);
        Assert.AreNotSame(container, child);
    }

    [TestMethod]
    public void CanRegisterInstance()
    {
        UnityCompositionContainer root = new UnityCompositionContainer();
        root.RegisterInstance(typeof (string), "foo", "bar");
        string returned = (string) root.Resolve(typeof (string), "foo");
        Assert.AreEqual("bar", returned);
    }


    [TestMethod]
    public void CanRegisterInstanceViaGenericWithoutName()
    {
        ICompositionContainer root = new UnityCompositionContainer();
        Foo f1 = new Foo();
        root.RegisterInstance<Foo>(f1);
        Foo returnedFoo = (Foo) root.Resolve(typeof (Foo));
        Assert.AreEqual(f1, returnedFoo);
    }

    [TestMethod]
    public void CanRegisterInstanceViaGenericWithName()
    {
        ICompositionContainer root = new UnityCompositionContainer();
        Foo f1 = new Foo();
        root.RegisterInstance<Foo>("asdf", f1);
        Foo returnedFoo = (Foo) root.Resolve(typeof (Foo), "asdf");
        Assert.AreEqual(f1, returnedFoo);
    }


    [TestMethod]
    public void CanResolveViaGenericWithoutName()
    {
        ICompositionContainer root = new UnityCompositionContainer();
        Foo f1 = new Foo();
        root.RegisterInstance<Foo>(f1);
        Foo returnedFoo = root.Resolve<Foo>();
        Assert.AreEqual(f1, returnedFoo);
    }

    [TestMethod]
    public void CanResolveInstanceViaGenericWithName()
    {
        ICompositionContainer root = new UnityCompositionContainer();
        Foo f1 = new Foo();
        root.RegisterInstance<Foo>("asdf", f1);
        Foo returnedFoo = root.Resolve<Foo>("asdf");
        Assert.AreEqual(f1, returnedFoo);
    }

    [TestMethod]
    public void UnityCompositionContainerImplementsIDisposable()
    {
        UnityCompositionContainer disposableContainer = new UnityCompositionContainer();
        Assert.IsNotNull(disposableContainer as IDisposable);
    }

    // This test is commented out intentionally. The purpose of this test is to show 
    // that if you use the generic version of the RegisterTypeMapping method, if the
    // types aren't compatible it'll fail at compile time. 
    // 
    // This is exactly what happens. However that also means this file won't compile.
    // The test is left in as comments, if you wish to verify this then remove the comments,
    // watch the compile file, and then comment it out again.

    //[TestMethod]
    //public void GenericTypeMappingRegistrationEnforcesCompileTimeCompatibility()
    //{
    //    UnityCompositionContainer root = new UnityCompositionContainer();
    //    root.RegisterType<IBar, Foo>();
    //}
}

Notice, there are no tests for the Services collection. This is intentional. We will see if we can avoid implementing the methods at all.

And here is the code to make those tests pass:

public class UnityCompositionContainer : ICompositionContainer, IDisposable
{
    private ICompositionContainer parent = null;
    private IUnityContainer wrappedContainer;

    public UnityCompositionContainer()
    {
        wrappedContainer = new UnityContainer();
    }

    private UnityCompositionContainer(UnityCompositionContainer parentContainer)
    {
        Parent = parentContainer;
        wrappedContainer = parentContainer.wrappedContainer.CreateChildContainer();
    }

    public ICompositionContainer Parent
    {
        get { return parent; }
        set { parent = value; }
    }

    public IServiceCollection Services
    {
        get { throw new NotImplementedException(); // return services; 
        }
    }

    public void RegisterInstance(Type t, object instance)
    {
        wrappedContainer.RegisterInstance(t, instance);
    }

    public void RegisterInstance(Type t, string name, object instance)
    {
        wrappedContainer.RegisterInstance(t, name, instance);
    }

    public void RegisterInstance<TInterface>(TInterface instance)
    {
        wrappedContainer.RegisterInstance<TInterface>(instance);
    }

    public void RegisterInstance<TInterface>(string name, TInterface instance)
    {
        wrappedContainer.RegisterInstance<TInterface>(name, instance);
    }

    public void RegisterType<TRequested, TReturned>() where TReturned : TRequested
    {
        wrappedContainer.RegisterType<TRequested, TReturned>();
    }

    public void RegisterType(Type requested, Type returned)
    {
        wrappedContainer.RegisterType(requested, returned);
    }

    public object Resolve(Type typeOfItem)
    {
        return wrappedContainer.Resolve(typeOfItem);
    }

    public object Resolve(Type typeOfItem, string name)
    {
        return wrappedContainer.Resolve(typeOfItem, name);
    }

    public T Resolve<T>()
    {
        return wrappedContainer.Resolve<T>();
    }

    public T Resolve<T>(string name)
    {
        return wrappedContainer.Resolve<T>(name);
    }

    public object BuildItem(IBuilder<WCSFBuilderStage> builder, object item)
    {
        throw new NotImplementedException();
    }

    public ICompositionContainer CreateChildContainer()
    {
        UnityCompositionContainer child = new UnityCompositionContainer(this);
        return child;
    }

    public void Dispose()
    {
        wrappedContainer.Dispose();
        wrappedContainer = null;
    }
}

We are now in a green state, time to check in.

Abusing Source Control

Agile teams usually check in very often. Some teams check in every time they hit green. I think that is a bit of overkill, unless you have a source control system with NO overhead. I check in when I complete a feature or a story, and usually at a few good, green stopping points in the process, like I have been doing. This was a good stopping point, and my next task is a bit risky, so this is a perfect time to check in.

This is a long enough post, even though I didn't do all that much, that I will call it quits for today. Next post, actually use the UnityCompositionContainer, and then nuke the old CompositionContainer.

Smart Client Software Factory – April 2008 Release is available on MSDN

mpuleio — Sat, 26 Apr 2008 03:25:00 GMT

The April 2008 release of the Smart Client Software Factory is now available at http://msdn2.microsoft.com/en-us/library/aa480482.aspx.

This is a port of the last release (May 2007, if I recall correctly) to VS2008. No new features were added. A few bugs were fixed, and a number of work items from CodePlex were closed.

This release supports Enterprise Library 3.1. It does not support Enterprise Library 4.0. If you want EntLib 4.0 (once it is released) you have the source code, and should be able to get it to work, if you really need to. I would not recommend it, as you will end up with two containers (Unity and the CAB container), which means code bloat and challenges deciding where objects should go.

Converting the Composite Web Application Block to Unity - Ummmm...Oooops.

mpuleio — Wed, 23 Apr 2008 02:57:00 GMT

This is the forth post in a series. The other post include

If you want background, go read the earlier posts.

Based upon feedback, I am making the source code available at CWAB and Unity.

In the last installment I wanted to remove the following from the ICompositionContainer:

~~static methods~~
~~Builder~~
~~Locator~~
~~Containers~~
Services

We completed the first four. In this installment, we will remove the Services collection, replacing it with using RegisterInstance and Resolve. After that, we will compare our ICompositionContainer to IUnityContainer, see what else we need to do, and may even pull in Unity.

Adding a few new methods

Before we do this, I want to add a generic overload to Resolve and one to RegisterInstance. I like the way the generic calls on Unity look, compared to all the typeof() and casting we have done so far.

I added the following tests, one at a time, and made them pass:

[TestMethod]
public void CanRegisterInstanceViaGenericWithoutName()
{
    ICompositionContainer root = new TestableRootCompositionContainer();
    Foo f1 = new Foo();
    root.RegisterInstance<Foo>(f1);
    Foo returnedFoo = (Foo)root.Resolve(typeof(Foo));
    Assert.AreEqual(f1, returnedFoo);
}

[TestMethod]
public void CanRegisterInstanceViaGenericWithName()
{
    ICompositionContainer root = new TestableRootCompositionContainer();
    Foo f1 = new Foo();
    root.RegisterInstance<Foo>("asdf", f1);
    Foo returnedFoo = (Foo)root.Resolve(typeof(Foo), "asdf");
    Assert.AreEqual(f1, returnedFoo);
}


[TestMethod]
public void CanResolveViaGenericWithoutName()
{
    ICompositionContainer root = new TestableRootCompositionContainer();
    Foo f1 = new Foo();
    root.RegisterInstance<Foo>(f1);
    Foo returnedFoo = root.Resolve<Foo>();
    Assert.AreEqual(f1, returnedFoo);
}

[TestMethod]
public void CanResolveInstanceViaGenericWithName()
{
    ICompositionContainer root = new TestableRootCompositionContainer();
    Foo f1 = new Foo();
    root.RegisterInstance<Foo>("asdf", f1);
    Foo returnedFoo = root.Resolve<Foo>("asdf");
    Assert.AreEqual(f1, returnedFoo);
}

In making them pass, I added the following to the ICompositionContainer interface:

T Resolve<T>();
T Resolve<T>(string name);
void RegisterInstance<TInterface>(TInterface instance);
void RegisterInstance<TInterface>(string name, TInterface instance);

This will help a bit with the look, feel, and style of the code, now for the real work.

Removing the Services Collection

Why do we want to remove the Services collection? Since Unity handles this sort of functionality, we can offload it entirely to Unity. This will cut a bit of code out of our implementation.

Let's do this the simple way, (I like to call it hack and slash development) and just remove the Services collection from the ICompositionContainer interface. This will result in a number of build errors (twenty or so, in fact). However, we can fix each of them easily. Any call to add a service becomes a RegisterInstance call, and any call to get a service becomes a Resolve call. So, we will hack each problem until we are in a green state again. The other option, for the less daring, is to search for all uses of Services, change them one at a time, and make sure we are green at each step. Today, I am feeling brave (read: reckless, or overly caffeinated), so I took the other approach. If I were pairing with someone, they would probably stop me. :-)

Once CWAB compiles, we still need to get the unit test library to compile. <click click click> <swear> <click click click>. The biggest challenge here is that Services.AddNew<T, IT> and RegisterType<IT, T> have the generic parameters in reversed order. Aaargh.

Everything compiles, but I have a problem: 34 unit tests are failing. This is not optimal. Now, why are they failing? After looking at the first few, it looks like I removed Services from the interface, and forgot to remove it from the CompositionContainer. The result is that some tests are still using the ServicesCollection. Oooops.

After removing Services from CompostionContainer, and getting everything to compile again, the test results are.....

Ouch! 40 failing unit tests. That is not good.

However, after some investigation, I can remove a couple of classes from our solution, as they are no longer necessary, and are just causing problems.

ServiceDependencyParameterResolver
ProviderDependencyParameterResolver
ProviderDependencyAttribute
ServiceDependencyAttribute

After removing them, there is a bit of code cleanup required, to remove references. All of the ServiceDependencyAttributes I replaced with ObjectBuilder DependencyAttributes. The ProviderAttributes, I commented out for the moment.

Wow. Progress. we are down to 37 failing tests. After looking at a few of them, where instances were not the same, I changed the SingletonPolicy in Resolve, and we are down to 24 failing tests.

Oh, gotta take a break.

<TimeWarp>Several Days Fly By</TimeWarp>

I got interrupted from getting this working the other day. Now, I am starting with broken tests. I hate that. I guess I was a bit too reckless. Well, I have a few options:

I can continue and see this through
I can timebox to a hour, and then roll back, and try again by taking smaller steps
I can give up now and try again from the last known good state.

I am going to opt for number 1.5: timebox to two hours, and depending on where I am, make a decision.

<timewarp duration="1 hour" />

@#$%^%$#@#$!!!

<timewarp duration="a few days" reason="I needed to think about it" />

I have determined that I got a bit overzealous. For the moment, the Services collection is necessary, and we can remove it once we have Unity in place to provide the necessary functionality. It will stay as part of the interface, and will continue to provide functionality until we no longer need it. However, it will eventually go away. How did I arrive at this conclusion? Well, I could not get the failing unit tests to pass in a reasonable amount of time. Moving the functionality requires a lot more code than is really practical for throw-away code. Oooops. Everyone makes mistakes.

As a result, I need to roll back a lot of changes. Unfortunately, I did not back up everything (or do a check in) before starting down the path of removing the services collection. Net result: I need to roll back everything, and then re-do the first half of this article. Double @#%$@%!

I'll revert and then rework the code up to the section Removing the Services Collection. I'll get the code posted (with the other source code) before I start the next installment.

However, I wanted to post this article sooner rather than later, so folks don't think I have dropped the series. Enjoy.

Converting the Composite Web Application Block to Unity - Clean Up ICompositionContainer

mpuleio — Thu, 10 Apr 2008 02:06:05 GMT

This is the third post in a series. The other post include

If you want background, go read the earlier posts.

Based upon feedback, I am making the source code available at CWAB and Unity.

In the last post, we started getting closer to my eventual goal. However, we still need to get rid of the static methods, Builder, Locator, Containers, and Services.

Why?

Static methods will make the necessary refactorings a pain in the.... well, a pain.
Builder and Locator are handled by Unity internally, and we no longer need to deal with them directly.
Containers will just be registered in the root container by module name, and we can use the WebClientApplication.FindModuleContainer method when we need to.
Then there are CWAB Services. These services will probably just go away. Global Services are types that are Registered on the Root Container as singletons, and module services are types registered on the appropriate Container as singletons. This will be really simple once we get Unity tied into the solution.

Once we get rid of these items on the interface, we will want to add a few from the IUnityContainer, namely CreateChildContainer, and at least a few overloads (if not all of them) for RegisterType, RegisterInstance, and Resolve.

Then, we will add a new type of container to the project, a CWABUnityContainer, and maybe a CompositionContainer factory. The CWABUnityContainer will be a facade that implements ICompositionContainer and hides a real UnityContainer under the hood. After that, things should be simple, allowing us to delete the old container and its code, and then do a bit of re-organizing.

Note: Since this is a proof of concept, not what I would call "shipping code", I have turned off creating XML comments in the solution. With the volume of changes, I was getting annoyed with all the warnings.

Removing Static Methods from CompositionContainer

There is only one static method on CompositionContainer, and it relies on the Locator property of the container object parameter to work. In removing this, we can simplify the type, and remove the only dependency on the Locator property. Let's change BuildItem to be a public, non-static method, and add it to the ICompositionContainer interface for a little while.

Everything compiles. Tests green (except for the ones I had commented out near the end of the last article.

Removing ObjectBuilder specific parts of the interface

Let's do these one at a time, starting with Builder. Comment it out in the interface, and....

Two parts of the test fixture fail to compile:

CreateRootContainerInitializesContainer needs a line commented out, since we changed the semantics of the method
MockWebClientApplication needs a change to the ApplicationBuilder property to return null for the moment, with a comment to come back later.

Now we can compile, and run the tests, and we are green. However, I did notice something that I want to take care of before I go any further.... IWebClientApplication has an ApplicationBuilder and a PageBuilder, which can go away. The Container will handle the responsibilities of these two properties. If we delete these properties from the interface, the MockWebClientApplication and WebClientApplication, we get some compile errors in WebClientApplication, which lead us down an ugly path. Instead, we will leave these properties ONLY in WebClientApplication, and make a note to delete them later.

Compile -> Good.

Tests -> Green.

Next Step, the Locator...

If we remove it from the interface, we have compilation problems in WebClientApplication.BuildItemWithCurrentContext where we call BuildItem. Let's roll back, change the signature of BuildItem to not have a locator, and the implementation to use the current container's locator, and then re-do the change. Again, we will leave the property only on the CompositionContainer, even though it is not part of the interface, and add a few comments. After a quick change to the test CreateRootContainerInitializesContainer, everything is green, and all tests pass.

The Containers collection

If we remove the Containers property from the ICompositionContainer interface, we have problems in the ModuleLoaderService. The ModuleLoaderService understands how the CompositionContainer works, and can add new containers (one for each module) to the collection. We also have challenges in the DefaultModuleContainerLocatorService, where we need to find a container in the collection. If we think about how Unity works, both of these problems can go away if we find another another way to get child containers, and to create child containers. Unity has the Resolve method, which can take a name parameter to get a named instance of an object (this handles getting a child container). We also have the CreateChildContainer method, to help with the creation, as well as RegisterInstance to give a created instance a name to use later.

Let's roll back removing the Containers property, add the RegisterInstance and Resolve methods (that use a name) to the interface, test them, then add the CreateChildContainer method to the interface, and test it. Once we have those pieces, we can re-work ModuleLoaderService and DefaultModuleContainerLocatorService to use the new methods. Once we do all that, we can remove Containers from the ICompositionContainer interface without problems.

So, let's start with RegisterInstance. Since I know whatever implementation I come up with is a throw away implementation, and it only needs to work well enough NOT to break the existing code, I am going to keep this simple.

First, a unit test added to CompositionContainerFixture:

[TestMethod]
public void CanRegisterInstance()
{
    TestableRootCompositionContainer root = new TestableRootCompositionContainer();
    root.RegisterInstance(typeof(string), "foo", "bar");
    string returned = (string) root.Resolve(typeof (string), "foo");
    Assert.AreEqual("bar", returned);
}

This tests for the behavior that Unity will have. I will add the following to the ICompositionContainer to get it to compile:

void RegisterInstance(Type t, string name, object instance);

And then add the stupid implementation:

public void RegisterInstance(Type t, string name, object instance)
{
}

Everything compiles, and the test fails, horribly.

Now, to get the test to pass, RegisterInstance becomes:

private Dictionary<string, object> _registeredInstances = new Dictionary<string, object>();
public void RegisterInstance(Type t, string name, object instance)
{
    _registeredInstances.Add(String.Concat(t.FullName, name), instance);
}

Now, I know that is an ugly, bad, horrible monstrosity of an implementation. It is also the simplest thing that will work. :-) I also know I could use OB to do this, but again, I am keeping things simple, knowing I will throw away the implementation in a few hours.

Resolve changes a bit too. I added an overloaded version, and then made the unit test above pass by making the code look like this:

public object Resolve(Type typeOfItem)
{
    string temporaryID = Guid.NewGuid().ToString();
    return Resolve(typeOfItem, temporaryID);
}

public object Resolve(Type typeOfItem, string name)
{
    string key = String.Concat(typeOfItem.FullName, name);
    if (_registeredInstances.ContainsKey(key))
    {
        return _registeredInstances[key];
    }
    
    PolicyList policies = new PolicyList();
    policies.Set<ISingletonPolicy>(new SingletonPolicy(false), typeOfItem, name);
    policies.Set<ICreationPolicy>(new DefaultCreationPolicy(), typeOfItem, name);
    policies.Set<IPropertySetterPolicy>(new PropertySetterPolicy(), typeOfItem, name);

    return _builder.BuildUp(
        _locator,
        typeOfItem,
        name,
        null,
        policies);
}

Compile. Run Tests. We are Green.

Now to add CreateChildContainer. First, we need a unit test:

[TestMethod]
public void CanCreateChildContainer()
{
    ICompositionContainer container = new TestableRootCompositionContainer();
    
    ICompositionContainer child = container.CreateChildContainer();
    Assert.IsNotNull(child);
    Assert.AreNotSame(container, child);
}

To make that compile and then pass, I added CreateChildContainer to the interface, the class, and then implemented it. Simple. And we are Green again.

Next step: remove from ICompositionContainer the Containers property, compile, and it fails. This requires minor tweaking to the ModuleLoaderService and DefaultModuleContainerLocatorService. Now, we compile. However, the Containers property is still on the CompositionContainer. After we remove it from there, we have to fix a lot of unit tests so that they compile (and removing a few that no longer make sense, semantically). This is simple, but tedious. <click> <click> <swearing> <click> <click> ...

Ok, we are now compiling and all unit tests pass.

I need a break, so we will cut this a little shorter than I had hoped.

In this installment I wanted to remove the following from the ICompositionContainer:

static methods
Builder
Locator
Containers
Services

We completed the first four. In the next installment, we will remove the Services collection, replacing it with using RegisterInstance and Resolve. After that, we will compare our ICompositionContainer to IUnityContainer, see what else we need to do, and may even pull in Unity.

Unity Shipped

mpuleio — Wed, 09 Apr 2008 02:06:05 GMT

I am a little late to the party, but Unity shipped last week.

Here are a few other posts about it:

Grigori: Unity DI container 1.0 shipped!
Chris: Unity 1.0 is released!

I have used Unity in an internal project here at p&p, as well as a proof of concept re-write of CWAB using Unity. The interface is clean and simple. It does what you want. Configuration is easy. It makes unit testing simpler via de-coupling. Unity rocks.

Data-mining for Code Quality Metrics

mpuleio — Thu, 03 Apr 2008 02:30:48 GMT

I spent two weeks between full time projects (still working on the 2 part time projects I am on) looking back at the build logs from the past 6 months (or so) trying to figure out what metrics we have, what we should track going forward, and what goals we should have for these metrics. I came up with some interesting findings.

First, overall unit test code coverage was OK, but not as high as I would like on my projects. Of course, these numbers included generated code, view code, and other things that I usually filter out. Also coverage was fairly flat. For the most part, as we added code, we added tests. This, I think is much better than one of the alternatives, having coverage drop over the course of the project.

Here is coverage for the Application Blocks in WCSF, without axis labels. The Y axis starts at 76% (not zero).

You will see that there was a noticeable drop in coverage part way through the project. That was when we added a new library of AJAX controls. Before the change was made we knew this would happen and accepted the risk. I also worked with the testers on my team to mitigate the risk via more acceptance tests and careful code reviews. And after the change, we trended up, slowly, over time.

In addition to watching coverage over time, I was able to come up with a few indices to watch going forward. Thanks to NDepend, a little bit of work parsing build logs, and Linq, I was able to create seven indices, three of which I will be watching closely on future projects:

Cyclomatic Complexity
Afferent Coupling
Efferent Coupling

If you want a definition for any of these, check out the NDepend site. The index for each of these is the average of the top 10 worst values by type.

Here is a graph of these indices over time for another, un-named project (without the axis labels)

You can see that the first few builds did not have NDepend hooked up properly. Then everything tracks along, relatively stable until about 40% through the project. The Dev Lead on the project was able to tell me what happened on the day that the Cyclomatic Complexity dropped drastically. It was a big change to simplify things.

Do these graphs, numbers, and indices (and all the others that I pulled from the data, but did not share yet) tell me the whole story as far as code quality? Of course not. However, these can all be used as indicators. If complexity trends sharply up over time, there may be a problem we need to investigate. If it stays low, there can still be other problems hidden. However, a little information is better than none.

Now, on to the next project...

Web Client Software Factory February 2008 Ships!

mpuleio — Thu, 28 Feb 2008 22:25:48 GMT

I know that folks have been reading about the Web Client Software Factory on Blaine's blog and on Glenn's blog. Blaine posted about what we planned to include, back in December with Next version of Web Client Software Factory (WCSF). Glenn had the post at the end of January, Web Client 2.0 closer than you think, and Web Client 2.0, what's the hold up?

So, what is in the latest version of the Web Client Software Factory?

Here is a quick blurb from the front page of our docs, with my comments in Blue:

The February 2008 release of the Web Client Software Factory is an update to the June 2007 release. The following are the major changes:

Added user interface responsiveness guidance. The guidance includes documentation, Web controls, QuickStarts, and a new reference implementation that demonstrate how to incorporate Microsoft ASP.NET AJAX technologies in your Web applications to provide a richer user interface experience.
Added support for the Model-View-Presenter pattern in user controls and master pages. The Composite Web Application Block includes a new Dependency Injection mechanism that facilitates the implementation of the Model-View-Presenter pattern in Web controls and master pages. The guidance package also includes new recipes that help developers create master pages and user controls that implement the Model-View-Presenter pattern. By using the Model-View-Presenter, developers can extend the testability surface to user controls and master pages.

Dependency Injection also works in ASMX Web Services hosted in a WCSF web application project

User controls can be reused across modules. Developers can build Web pages made up of user controls from different modules.

There is an example of this in the Order Management Reference Implementation

Updated the Composite Web Application Block. The main changes include the following:

Improved performance
Support for services registration through configuration
Support for type mapping for dependency injection

Type mapping was a no-brainer to add. We also needed it to show a few of the deeper concepts around MVP.

The performance improvements are the part of how the new Unity project works deep under the hood. Chris Tavares and worked with the WCSF team on the performance enhancements. Later, Chris went to start the Unity project, which has evolved into a great tool from what I have seen. I know the next question is "When will WCSF support Unity?" My answer is as soon as we can do a complete re-write. Out of the box, Unity provides a lot of functionality that CWAB provides. To properly use Unity, we would need to throw out a lot of the CWAB code, and re-do it.

The ability to add a service via config was requested by the community, and is shown in the Order Management Reference Implementation.

Updates to the Add Business Module and Add Foundational Module recipes. These recipes now include a new option to create a separate project for the modules’ public interface.
Updated the patterns documentation topics. The main changes include two new pattern description topics, Inversion of Control and Module Interface Separation, and it updates to the Model-View-Presenter topic.
Included additional guidance for several technical concepts. The technical concepts covered are views testability, modularity, autocomplete, validation, and search. The guidance consists of documentation, QuickStarts, Web controls, and How-to topics.

These concepts were shipped previously as "Bundles" on our CodePlex community. We will be releasing new, updated VS2008 versions of these bundles on MSDN in the near future, but all the content is in the factory. The bundles are so folks can get a small taste and look at a single feature or concept in isolation.

Added support for Visual Studio 2008 to the guidance package.

VS2008 and and .NET 3.5 support was asked for very loudly by customers.

Testing Guidance

Something we do not talk about enough is the fact that we are releasing some guidance on how to test web applications. First, since we do most development via ~~TDD~~ EDD (Example Driven Development), we have quite a bit in the way of unit tests. There are a few exceptions, where we intentionally do not include unit tests as we do not want to clutter a QuickStart example with another concept that may hinder understanding of what the QuickStart is about.

We are also shipping acceptance tests. In a few projects, these acceptance tests are manual test scripts in the form of a Visual Studio Manual Test. In others, we have completely automated the acceptance tests using

<TheLawyersMadeMeSayIt>

Note: this is a link to an external Web site that provides software that can be used to write acceptance tests. Please note that Microsoft is not responsible for the content of external Internet sites.

</TheLawyersMadeMeSayIt>

the WatiN (Web Application Testing in .NET).

To compile the test projects and run the tests, you will need VS2008 Professional or Team System, and to download the WatiN binaries, and copy the DLLs to the Lib folder (which our help describes with more info). The upside is that anyone can see how we are doing functional/acceptance testing of our sample applications. Of course, there is a lot more to testing than just acceptance testing, but it is a start.

Other resources

The WCSF page on MSDN
The WCSF Community on CodePlex
If you just want to peruse the docs, check out the WCSF Documentation download page

You will also want to check out what Blaine and Glenn say about the release:

Blaine's post: Web Client Software Factory Shipped
Glenn's post: Web Client Software Factory 2.0 Shipped

Unit testing is evolving

mpuleio — Fri, 21 Sep 2007 02:01:19 GMT

Jim Newkirk (of nUnit fame and one of the Microsoft folks behind www.CodePlex.com ) has been blogging about unit testing in forever ( most recently: Why you should not use Setup and Teardown in NUnit ).

Now, Jim and Brad Wilson are putting action to his words and codifying lessons learned over the years by developing xUnit.Net. Check out Jim's intro to this new tool at "Announcing xUnit.net".

Personally, I'll try using the shipping version on my own personal projects. At this point, it will probably not effect what I do at p&p.

Check it out and enjoy.

[Note: I added the testing flag since xUnit.NET claims to be extensible into an acceptance testing framework. Not that I consider EDD testing.]

Using the Testable Object Pattern

mpuleio — Tue, 03 Apr 2007 19:41:00 GMT

Wow. Five posts on unit testing and/or EDD in a row... this has got to be a record.

Brad has a great post on the Testable Object Pattern. I've used this pattern on my own code without realizing it, as I also don't like "magic" setup and tear down methods that rely on a particular implementation of a unit testing framework.

Enjoy writing those examples first.

Design as If Testing Matters

mpuleio — Thu, 29 Mar 2007 20:05:00 GMT

To continue with the string of unit testing and Example Driven Design posts, here is another one:

Gordon Weakliem has a post about designing APIs with testing in mind, which links to a James Robertson post on API Design as if Unit Testing Mattered.

The idea, distilled, is this:

If your API is hard to unit test, how in the heck are your users going to be able to use it?

Unit Testing Rules

mpuleio — Wed, 28 Mar 2007 20:12:00 GMT

One of the internal Microsoft discussion lists on unit testing and EDD (TDD) had a thread where a person new to unit testing asked a couple of really good questions. In response, someone posted a link to an intersting post by Michael Feathers on A Set of Unit Testing Rules

I like these rules, and am going to share them with my team as suggested guidelines to make sure we are consistent.

Unit Testing will be in Visual Studio Pro

mpuleio — Tue, 27 Mar 2007 22:31:00 GMT

It was publically announced today on Naysawn Naderi's blog that Unit Testing will be in the Pro SKU of the next version of Visual Studio.

This is fantastic news that I am very excited to share.

Creating a List of Examples (a.k.a. a Test List)

mpuleio — Tue, 27 Mar 2007 20:09:00 GMT

Brian has a great post on how to get an EDD (Example Driven Design) coding session started with a list of examples. Of course, Brian uses the terms "TDD" and "Creating a Test List", but the idea is the same.

[Author's Note: Because TDD (Test Driven Design) is such an overloaded term, and misleads people into thinking about TESTING rather than DESIGNING, I have stopped using the term. EDD is a much better description of the process and the mindset. Testing is just a great, beneficial side effect of the process.]

Announcing: Web Client Software Factory Webcast

mpuleio — Tue, 20 Mar 2007 04:49:26 GMT

Through a few, lucky quirks of fate, Blaine Wastell and I get to do an MSDN webcast about the Web Client Software Factory on Wednesday, March 21 at 10:00AM PST. I'm looking forward to it.

If you are interested in an overview of the factory, a few demos, and an in-depth (time permitting) review of unit testing with the View-Presenter pattern, and an overview of Page Flow, you can register for the show here :

MSDN Webcast: How to Use the Web Client Software Factory (Level 300)