This post started to get a little long, so I won’t re-explain the concept.

Joshua Flanagan wrote a nice overview at his Los Techies blog: Auto mocking Explained.

My post is mainly here to describe the Unity version of an automocking container I threw together.

In Jan 2009 I blogged about my initial version of the Unity AutoMocker - Why am I blogging about it again?

I originally wrote the AutoMocker for the Unity container a year ago (Jan 2009, in Silverlight), and finally got around to placing the code up in the moq-contrib project in June of 2009.

I’m writing another post today in hopes to:

1. Get some feedback on how this little snippet of code should continue.
2. Give a little more how-to/example code
3. Describe some updates I made since I originally created it. 

Where can I get it?

This is one part where I’d appreciate some feedback.

I have two slightly different versions out there (currently).

I have one version at the ElegantCode repository where I was working on it, and the other I threw up at moq-contrib.

The core of the UnityAutoMockContainer is the same in both places, it’s how the tests are separated out that differ.

In the ElegantCode repository it’s an all in one self contained single file (that you can copy into your own test project(s)). You can then setup a single test in your own testing framework that runs all internal automocker tests (in case you need to modify it yourself, and don’t want to break any existing functionality). EX: test

[Test]
public void Should_run_all_UnityAutoMockContainer_internal_tests()
{
    Moq.AutoMocking.SelfTesting.UnityAutoMockContainerFixture
        .RunAllTests(Console.WriteLine);
}

I kind of like this format as it makes it easy to port between test libraries. Can’t say I like having the tests in the same file as the core, but it certainly is not a large chunk of code (so far) so it’s relatively small to maintain and definitely easier to manage as a single .cs file than another assembly (which would have to be version dependent on both Unity and Moq).

The moq-contrib is definitely where I think this helper should end up (and it is there). I just happened to break the tests out into the Silverlight test project and the core is alone in a file.

It’s current state isn’t as easy to copy to a test library (Silverlight/Desktop/Unity 1.2/Unity 2.0) as the one at ElegantCode. What does anyone think? Should I put them all together in one file?

However it ends up (1. all in one file or two (1 test) (1 core)) it will continue to be maintained on the moq-contrib project.

What is the high level API of the container?

It’s pretty simple, (currently) there are four methods on the container.

Two for registering items with the container. Say you want to register an already created instance, or say you want to map an interface to a concrete class and _not_ have the container generate mocks automatically for special cases.

And two for pulling items out of the container. Whether you want a instance of T or a Mock<T>, it gives you ways to retrieve both.

How can I setup my own registrations with the container?

Say I don’t want to have the container generate mocks for specific items and I want to supply specific configuration to the UnityContainer.

public UnityAutoMockContainer RegisterInstance<TService>(TService instance)

public UnityAutoMockContainer Register<TService, TImplementation>()
                where TImplementation : TService

Note: both of these registration methods return the container itself so you can fluently stack registration. EX:

AutoMockContainer
    .Register<IServiceA, ServiceA>()
    .Register<IServiceB, ServiceB>();

Let me know: I haven’t tested or played around with how this automocking container deals with any container specific xml configuration… So although I don’t think you should probably have that in a test assembly (stuff happens). Let me know if there are any issues.

How do I get items out of the container?

First is the Resolve<T>(). It will pull an item T out of the container. (Creating it if not already existing)

public T Resolve<T>()

When T is an interface Resolve<T> (unless you setup registration specifically with the container) should return basically “(new Mock<T>()).Object”

When T is a concrete Class, the container should return an instance of T and any of it’s dependencies will be satisfied by mocks. (Note that T will not be any sort of mocked instance of T, unless you used the GetMock<T> as described below first)

public Mock<T> GetMock<T>() where T : class

When T is an interface GetMock<T> should return basically “(new Mock<T>())”

When T is a concrete Class, the container should return a new Mock<T>() and any of it’s dependencies will be satisfied by mocks.

How do I use the UnityAutoMockContainer?

It’s pretty basic, you first create an instance of the UnityAutoMockContainer, and from there you can ask it for mocks of an (Interface, Class, or Abstract Class).

If you request an instance of a concrete class, or abstract class, the UnityAutoMockContainer will stuff mocks in for any constructor dependencies of your concrete class (if it can). You can then request from the container those same dependencies one at a time and either apply mocking setups or verifications.

NOTE: Anything the container creates will live as a singleton instance in the container. So any other requests from the container will always return the originally created instance. Therefore, each distinct scenario in a test suite should have their own instances of the container.

Below his an example of how you can leverage the container in some tests. Given this base fixture class…

public class FixtureBase
{
    private readonly UnityAutoMockContainer _autoMockContainer = new UnityAutoMockContainer();

    protected UnityAutoMockContainer AutoMockContainer
    {
        get { return _autoMockContainer; }
    }

    [TestFixtureSetUp]
    public void SetupContext_ALL()
    {
        Before_all_tests();
        Because();
    }

    [TestFixtureTearDown]
    public void TearDownContext_ALL()
    {
        After_all_tests();
    }

    protected virtual void Before_all_tests()
    {
    }

    protected virtual void Because()
    {
    }

    protected virtual void After_all_tests()
    {
    }
}

If I were given the following system to test.

public interface IServiceA { void RunA(); }
public interface IServiceB { void RunB(); }

public class TestComponent
{
    public TestComponent(IServiceA serviceA, IServiceB serviceB)
    {
        ServiceA = serviceA;
        ServiceB = serviceB;
    }

    public IServiceA ServiceA { get; private set; }
    public IServiceB ServiceB { get; private set; }

    public void RunAll()
    {
        if (!HowDidItGo())
            return;
        ServiceA.RunA();
        ServiceB.RunB();
    }

    public virtual bool HowDidItGo()
    {
        // some really nasty untestable code
        return true;
    }
}

The below example demonstrates simply verifying some behavior on the mocked dependencies of the system under test.

[TestFixture]
public class Example__how_to_pull_items_from_the_UnityAutoMockContainer_when_verifying_behavior_after_an_action_was_taken 
    : FixtureBase
{
    private TestComponent _testComponent;

    protected override void Before_all_tests()
    {
        base.Before_all_tests();
        _testComponent = AutoMockContainer.Resolve<TestComponent>();
    }

    protected override void Because()
    {
        _testComponent.RunAll();
    }

    [Test]
    public void Should_run_ServiceA_RunA()
    {
        AutoMockContainer
            .GetMock<IServiceA>()
            .Verify(v => v.RunA(), Times.Once());
    }

    [Test]
    public void Should_run_ServiceB_RunB()
    {
        AutoMockContainer
            .GetMock<IServiceB>()
            .Verify(v => v.RunB(), Times.Once());
    }
}

Next, you may have noticed that the system under test had a complicated internal method (that may not necessarily be testable). You can use the AutoMocker to create the system under test as a Mock itself, so we can override some of the behavior. Here’s how you could quickly do that.

Aside: I’m not saying this is a good practice or aids in good component design, just saying it’s possible

[TestFixture]
public class Example__how_to_use_the_UnityAutoMockContainer_to_override_a_method_on_the_SystemUnderTest_to_test_a_certain_behavior
    : FixtureBase
{

    private TestComponent _testComponent;

    protected override void Before_all_tests()
    {
        base.Before_all_tests();
        var mockTestComponent = AutoMockContainer.GetMock<TestComponent>();

        mockTestComponent
            .Setup(s => s.HowDidItGo())
            .Returns(false);

        _testComponent = mockTestComponent.Object;
    }

    protected override void Because()
    {
        _testComponent.RunAll();
    }

    [Test]
    public void Should_run_ServiceA_RunA()
    {
        AutoMockContainer
            .GetMock<IServiceA>()
            .Verify(v => v.RunA(), Times.Never());
    }

    [Test]
    public void Should_run_ServiceB_RunB()
    {
        AutoMockContainer
            .GetMock<IServiceB>()
            .Verify(v => v.RunB(), Times.Never());
    }
}

It’s amazing how much redundant test setup code this little helper has saved me in my tests. I hope others can find some use with this as well.

What is it? (Silverlight Testing Automation Tool)

Where can I get StatLight?

Happy Coding !!!

The Examples

[Subject(typeof(CoffeeMachine),"using vanilla Rhino.Mocks")]
public class Example01_when_preparing_coffee_grounds
{
    Establish context = () =>
        {
            Grinder = MockRepository.GenerateMock<IGrinder>();
            Hopper = MockRepository.GenerateMock<IHopper>();
            Hopper.Expect(x => x.HasBeans()).Return(true);
            CoffeeMachine = new CoffeeMachine(Grinder, Hopper);
        };

    Because of = () => _coffeeMachine.PrepareCoffeeGrounds(12);

    It should_check_if_hopper_has_beans = () => Hopper.VerifyAllExpectations();
    It should_grind_coffee = () => Grinder.AssertWasCalled(x => x.Grind(12));

    static IGrinder Grinder;
    static IHopper Hopper;
    static CoffeeMachine CoffeeMachine;
}

• Make BDD Your BFF
• Step by Step to Using MSpec (Machine.Specifications) with ReSharper
• MSpec - Take 2
• MSpec BDD framework installer
• Updated! From the Morning Brew #487: BDD with MSpec and Rhino Auto Mocks, parts  1, 2, and 3 Here is the same specification using the RhinoAutoMocker<T> class provided by StructureMap.AutoMocking:

[Subject(typeof(CoffeeMachine),"using RhinoAutoMocker<CoffeeMachine>")]
public class Example02_when_preparing_coffee_grounds
{
    Establish context = () =>
        {
            CoffeeMachine = new RhinoAutoMocker<CoffeeMachine>();
            Grinder = CoffeeMachine.Get<IGrinder>();
            Hopper = CoffeeMachine.Get<IHopper>();
            Hopper.Expect(x => x.HasBeans()).Return(true);
        };

    Because of = () => v.ClassUnderTest.PrepareCoffeeGrounds(12);

    It should_check_if_hopper_has_beans = () => Hopper.VerifyAllExpectations();
    It should_grind_coffee = () => Grinder.AssertWasCalled(x => x.Grind(12));

    static IGrinder Grinder;
    static IHopper Hopper;
    static RhinoAutoMocker<CoffeeMachine> CoffeeMachine;
}

[Subject(typeof(CoffeeMachine),"using RhinoAutoMocker base")]
public class Example03_when_preparing_coffee_grounds : with_rhinoautomocker
{
    Establish context = () => Hopper.Expect(x => x.HasBeans()).Return(true);

    Because of = () => CoffeeMachine.ClassUnderTest.PrepareCoffeeGrounds(12);

    It should_check_if_hopper_has_beans = () => Hopper.VerifyAllExpectations();
    It should_grind_coffee = () => Grinder.AssertWasCalled(x => x.Grind(12));

}

[Subject("using RhinoAutoMocker<T>")]
public class with_rhinoautomocker
{
    protected static IGrinder Grinder;
    protected static IHopper Hopper;
    protected static RhinoAutoMocker<CoffeeMachine> CoffeeMachine;

    Establish context = () =>
    {
        CoffeeMachine = new RhinoAutoMocker<CoffeeMachine>();
        Grinder = CoffeeMachine.Get<IGrinder>();
        Hopper = CoffeeMachine.Get<IHopper>();
    };
}

However, we are still initializing and accessing the class in a less than optimal manner.To make the usage of the container a little more seamless, I decided to create a wrapper and factory for the AutoMocker.  Setup of the dependencies and expectations are done through an AutoMocker wrapper object.  The instance of the class under test is accessed through a ClassUnderTest object.

The Result

The specification (and base class) now look like this:

[Subject(typeof(CoffeeMachine),"using coffee machine base")]
public class Example05_when_preparing_coffee_grounds : with_coffee_machine
{
    Establish context = () => Hopper.Expect(x => x.HasBeans()).Return(true);

    Because of = () => ClassUnderTest.PrepareCoffeeGrounds(12);

    It should_check_if_hopper_has_beans = () => Hopper.VerifyAllExpectations();
    It should_grind_coffee = () => Grinder.AssertWasCalled(x => x.Grind(12));
}

[Subject("using SpecificationFor<CoffeeMachine>")]
public class with_coffee_machine : SpecificationFor<CoffeeMachine>
{
    protected static IGrinder Grinder;
    protected static IHopper Hopper;

    public with_coffee_machine
    {
        Grinder = AutoMocker.Get<IGrinder>();
        Hopper = AutoMocker.Get<IHopper>();
    }
}

As you can see, the base class inherits from SpecificationFor<T>.  The default constructor uses Rhino.Mocks(MockMode.AAA) to generate the dependencies.  It then exposes a AutoMocker object, which is just the wrapper around the AutoMocker base class.  It also exposes a ClassUnderTest object.  If I didn’t need to use the dependencies, I could make the Example05_when_preparing_coffee_grounds class inherit from SpecificationFor<CoffeeMachine> instead of inheriting from the base class.

The Code

I have included the code for the wrapper below for your review.  The code and six examples are available on my Google code repository. The repository also includes an example using the MoqAutoMocker.  All the examples have the same assertions, but are built up using the different techniques.

namespace CodeProgression.Framework.Testing
{
    public abstract class SpecificationFor<T> where T: class
    {
        protected static ClassUnderTest<T> Factory;

        // UPDATE 2009-12-21:
        //   Moved initialization here
        protected static T ClassUnderTest {get {return AutoMocker.Instance;} }

        protected SpecificationFor()
        {
            AutoMocker = AutoMockFactory.CreateTarget<T>();

            // UPDATE 2009-12-21:
            //    Initializing here prevented injected dependencies!
            // AutoMocker.PartialMockTheClassUnderTest();
            // ClassUnderTest = AutoMocker.Instance;
        }

        protected SpecificationFor(AutoMockType type)
        {
            AutoMocker = AutoMockFactory.CreateTarget<T>(type);

            // UPDATE 2009-12-21:
            // Initializing here prevented injected dependencies!
            // AutoMocker.PartialMockTheClassUnderTest();
            // ClassUnderTest = AutoMocker.Instance;
        }
    }

    public static class AutoMockFactory
    {
        public static ClassUnderTest<TARGETCLASS> CreateTarget<TARGETCLASS>() where TARGETCLASS : class
        {
            return CreateTarget<TARGETCLASS>(AutoMockType.RhinoMocksAAA);
        }

        public static ClassUnderTest<TARGETCLASS> CreateTarget<TARGETCLASS>(AutoMockType framework) where TARGETCLASS : class
        {
            AutoMocker<TARGETCLASS> mocker;
            ServiceLocator serviceLocator;
            switch (framework)
            {
                case AutoMockType.RhinoMocksAAA:
                    mocker = new RhinoAutoMocker<TARGETCLASS>(MockMode.AAA);
                    serviceLocator = new RhinoMocksAAAServiceLocator();
                    break;
                case AutoMockType.RhinoMocksClassic:
                    mocker = new RhinoAutoMocker<TARGETCLASS>(MockMode.RecordAndReplay);
                    serviceLocator = new RhinoMocksClassicServiceLocator();
                    break;
                case AutoMockType.Moq:
                    mocker = new MoqAutoMocker<TARGETCLASS>();
                    serviceLocator = new MoqServiceLocator();
                    break;
                default:
                    throw new ArgumentOutOfRangeException("framework");
            }
            return new ClassUnderTest<TARGETCLASS>(mocker, serviceLocator);
        }
    }

    public enum AutoMockType
    {
        Moq,
        RhinoMocksAAA,
        RhinoMocksClassic
    }

    public class ClassUnderTest<TARGETCLASS> where TARGETCLASS : class
    {
        readonly IAutoMocker<TARGETCLASS> _mocker;
        readonly ServiceLocator _serviceLocator;

        public ClassUnderTest(IAutoMocker<TARGETCLASS> mocker, ServiceLocator serviceLocator)
        {
            _mocker = mocker;
            _serviceLocator = serviceLocator;
        }

        public AutoMockedContainer Container
        {
            get { return _mocker.Container; }
        }

        public TARGETCLASS Instance
        {
            get { return _mocker.ClassUnderTest; }
        }

        public void MockObjectFactory()
        {
            _mocker.MockObjectFactory();
        }

        public void PartialMockTheClassUnderTest()
        {
            _mocker.PartialMockTheClassUnderTest();
        }

        public T Get<T>() where T : class
        {
            return _mocker.Get<T>();
        }

        public void Inject(Type pluginType, object stub)
        {
            _mocker.Inject(pluginType, stub);
        }

        public void Inject<T>(T target)
        {
            _mocker.Inject(target);
        }

        public T AddAdditionalMockFor<T>() where T : class
        {
            return _mocker.AddAdditionalMockFor<T>();
        }

        public void UseConcreteClassFor<T>()
        {
            _mocker.UseConcreteClassFor<T>();
        }

        public T[] CreateMockArrayFor<T>(int count) where T : class
        {
            return _mocker.CreateMockArrayFor<T>(count);
        }

        public void InjectArray<T>(T[] stubs)
        {
            _mocker.InjectArray(stubs);
        }

        public T Mock<T>() where T : class
        {
            return _serviceLocator.Service<T>();
        }
        public object Mock(Type serviceType)
        {
            return _serviceLocator.Service(serviceType);
        }
        public T PartialMock<T>() where T : class
        {
            return _serviceLocator.PartialMock<T>();
        }
    }
}

FYI: I’m very new to PowerShell, so any suggestions on how I implemented the below are welcome…

Examples of end result ShouldLookLike()…

Step 1: Figure out how to write a C# style extension method in PowerShell.

I found a great blog post describing how to extend any PowerShell object to add extension methods. Extension Methods in Windows PowerShell

<?xml version="1.0" encoding="utf-16"?>
<Types>
    <Type>
        <Name>System.Object</Name>
        <Members>
            <ScriptMethod>
                <Name>ShouldBeFalse</Name>
                <Script>
                    [NUnit.Framework.Assert]::IsFalse($this)
                </Script>
            </ScriptMethod>
            <ScriptMethod>
                <Name>ShouldBeTrue</Name>
                <Script>
                    [NUnit.Framework.Assert]::IsTrue($this)
                </Script>
            </ScriptMethod>
            <ScriptMethod>
                <Name>ShouldEqual</Name>
                <Script>
                    [NUnit.Framework.Assert]::AreEqual($args[0], $this)
                </Script>
            </ScriptMethod>
            <ScriptMethod>
                <Name>ShouldNotEqual</Name>
                <Script>
                    [NUnit.Framework.Assert]::AreNotEqual($args[0], $this)
                </Script>
            </ScriptMethod>
        </Members>
    </Type>
</Types>

NOTE: the file HAS to be saved with the extension .ps1xml Ex: NunitSpecificationPowerShellExtensions.ps1xml

Step 2: Load the extended type definition into the PowerShell runtime.

Update-TypeData -PrependPath NunitSpecificationPowerShellExtensions.ps1xml

[System.Reflection.Assembly]::LoadFrom("C:\Program Files\NUnit 2.5.2\bin\net-2.0\framework\nunit.framework.dll") | Out-Null

#
# Update-TypeData -prependPath C:\Code\NunitSpecificationPowerShellExtensions.ps1xml
#

[System.Reflection.Assembly]::LoadFrom("C:\Program Files\NUnit 2.5.2\bin\net-2.0\framework\nunit.framework.dll") | Out-Null

$true.ShouldBeTrue()

$false.ShouldBeFalse()

"a".ShouldEqual("a")

"a".ShouldNotEqual("b")

Jeremy’s other contributions to the community include StructureMap and an obtuse fascination with separation patterns for user interfaces.

Story Teller is an alternative for Fitnesse, implemented in .NET and chases the holy grail of executable requirements. If you are interested in how to achieve the promise of shared and executable requirements, this just might be your tool.

• Story Teller
• Jeremy’s StoryTeller post on a preview release

Get the show here

I like to use Object Mothers in my test projects, especially when I have a large number of services or entities I need to feed into the things I am testing. For example, if I have a class I am testing that takes a constructor argument, I may set it up in my test like this:

   1: protected override void Arrange()

   2: {

   3:     _recipeController = new RecipeController(new RecipeEntity());

   4: }

Since I probably don’t want to pass in a real RecipeEntity I can obviously mock one. (Also, don’t freak over the fact that I am injecting a single entity into a controller. This isn’t the point of the post.)

   1: protected override void Arrange()

   2: {

   3:     Mock<IRecipeEntity> moqRm = new Mock<IRecipeEntity>();

   4:     _recipeController = new RecipeController(moqRm.Object);

   5: }

And this is all old hat goodness. It turns out that I find I want to mock IRecipeEntity a lot. And because of that, I can put it up in my context class OR I can get the mock through an object mother.

This is especially useful when I need to build up a complex set of dependencies. So without further delay, here is a mother implementation that mocks up a complete entity.

   1: public static class DomainEntityMother

   2:    {

   3:        public static IRecipeEntity Moq_IRecipeEntity()

   4:        {

   5:            Guid id = Guid.NewGuid();

   6:  

   7:            var moq = new Mock<IRecipeEntity>();

   8:                moq.SetupGet(m => m.Id).Returns(id);

   9:                moq.SetupGet(m => m.Title).Returns("Recipe : " + id);

  10:                moq.SetupGet(m => m.CooksNotes).Returns("Notes : " + id);

  11:                moq.SetupGet(m => m.Ingredients).Returns(DomainEntityMother.Moq_IIngredientEntities());

  12:  

  13:  

  14:            return moq.Object;

  15:        }

  16:  

  17:        public static IList<IIngredientEntity> Moq_IIngredientEntities()

  18:        {

  19:            var ingredientEntities = new List<IIngredientEntity>();

  20:                ingredientEntities.Add(Moq_IIngredientEntity());

  21:                ingredientEntities.Add(Moq_IIngredientEntity());

  22:                ingredientEntities.Add(Moq_IIngredientEntity());

  23:                ingredientEntities.Add(Moq_IIngredientEntity());

  24:  

  25:            return ingredientEntities;

  26:        }

  27:  

  28:        private static int ingredientCounter = 0;

  29:  

  30:        public static IIngredientEntity Moq_IIngredientEntity()

  31:        {

  32:            ingredientCounter++;

  33:            Guid id = Guid.NewGuid();

  34:            var moq = new Mock<IIngredientEntity>();

  35:            moq.SetupGet(m => m.Amount).Returns(ingredientCounter.ToString);

  36:            moq.SetupGet(m => m.Unit).Returns("TBSP");

  37:            moq.SetupGet(m => m.Description).Returns("Ingredient : " + id);

  38:            moq.SetupGet(m => m.Id).Returns(id);

  39:            return moq.Object;

  40:        }

  41:  

  42:        public static IList<IRecipeEntity> Moq_IRecipeEntities()

  43:        {

  44:            IList<IRecipeEntity> recipeEntities = new List<IRecipeEntity>();

  45:            for (int i = 0; i < 5; i++)

  46:            {

  47:                recipeEntities.Add(Moq_IRecipeEntity());

  48:            }

  49:            return recipeEntities;

  50:        }

  51:    }

And now my test reads like this:

   1: protected override void Arrange()

   2: {

   3:     _recipeController = new RecipeController(DomainEntityMother.Moq_IRecipeEntity());

   4: }

Now, this is cool, but what if I want to make a bad entity? One that should make my test fail, for instance? Do I need another mother? Nope, I just use the one the mother created, an mess with it a little.

   1: protected override void Arrange()

   2: {

   3:     var moqEntity = Mock.Get(DomainEntityMother.Moq_IRecipeEntity());

   4:         moqEntity.SetupGet(m => m.Id).Returns(Guid.Empty);

   5:     _recipeController = new RecipeController(moqEntity.Object);

   6: }

Now I can create all those boundary condition tests that SHOULD fail by starting with a good entity and then only changing the parts I want to cause to be invalid.

I never really ended up using MSpec on things at work. There were lots of lame reasons:

• We were using MbUnit and MSpec worked with NUnit (like I really care, seriously)
• We already had lots of existing tests and didn't want the disjointed feeling of having two ways to do things
• I was already struggling at work getting people to adopt the new things I had already introduced into our environment.

I took what I could out of MSpec and the other Spec Driven Development stuff I got from the community and kind of rolled my own style of doing spec driven development just using MbUnit. I've since gathered that there are lots of people doing this.

Recently I had to do a small sample application in a short period of time. It wasn't for work (i.e. no MbUnit legacy) and I still wanted to do it spec first, so I grabbed the latest MSpec and used that.

I noticed there are several small but appreciated changes that have been made since the last time I used MSpec, namely:

XUnit and (kind of) Gallio Support

To use Gallio/MbUnit or xUnit with MSpec, there's really nothing special to do - just reference the testing framework you want to use and the adapter assembly.

The adapter assembly is the magic part of MSpec. It helps the unit testing framework build a model of the tests to run. When using MSpec, you're not putting attributes on things anymore to indicate they are unit tests. The adapter is needed so the unit testing framework knows what to run as tests.

For NUnit and xUnit, there are a bunch of nice extension methods defined for doing systemUnderTest.ShouldXXX() style assertions. There aren't any for MbUnit, but I made some in my fork of MSpec if you're interested.

I imagine you could write an adapter for MSTest, as well as some extension methods, but my interest in MSTest-ifying MSpec this ends there.

Once you start using these extension methods, the unit testing framework dependencies kind of melt away:

public class when_pricing_an_item_that_requires_no_sales_tax : with_an_item_to_price
{
    static Money price;

    Because of = () => {

        the_product.is_not_taxed()
                   .when_shipped_to(our_destination);

        price = pricingService.PriceItem(1, the_product, our_destination);
    };

    It prices_as_the_base_price = () =>
        price.ShouldEqual(our_base_price);
}

Where's the test framework code? Does this use NUnit? MbUnit? The only assertion here is in ShouldEqual, which is one of those extension methods that calls who cares which unit testing framework.

That's the real lesson here: who cares which unit testing framework you're using - that decision doesn't add any value to your product, and doesn't make this a valid excuse for not using MSpec. If one framework or the other works better with your build process or some tool you are using, just use that framework.

Pending

    public class when_pricing_an_item_that_requires_sales_tax_where_we_are_shipping : with_an_item_to_price
    {
            It includes_the_tax_in_the_price;
            It includes_the_tax_in_the_total_tax;
            It doesnt_include_the_tax_in_the_subtotal;
            It doesnt_include_the_tax_in_the_line_item_total;
    }

I saw Aaron demo this somewhere once, maybe at an #altnetseattle meeting or something, but I didn't get it at first. I thought it was about going off and writing a bunch of Tests then implementing them. My view that you write one Test, then implement, then another, etc.

The difference is, when doing things Spec first, it's...well...it's just different. I think one reason I like one test at a time is that I am testing close to the implementation at that point. Since I am in the process of designing the system while doing TDD, I don't know what the rest of the design is going to look like till I get there. If I write too many tests, I am speculating about what the design is going to look like.

Specs aren't so much about the physical design of the system so they don't change (as much) as the design evolves. If they do, they have good (read: business) reason. It's not wrong to translate specs into code as part of the same process you are getting them (ex.: talking with a product owner...taking notes in the form of "public class whatever_context { It does_this; It does_that; ...}".) That process is unlikely to be as granular as TDD tests, as no business person that is making money wants to hold your hand all day while they spoon feed you one thing at a time.

The output from running the above specs is:

when pricing an item that requires sales tax where we are shipping
>> includes the tax in the price (NOT IMPLEMENTED)
>> the tax in the total tax (NOT IMPLEMENTED)
>> include the tax in the subtotal (NOT IMPLEMENTED)
>> include the tax in the line item total (NOT IMPLEMENTED)

You can go ahead and spec things out ahead of time just saying "It does_whatever" and you'll get a nice report of what's to be done.

Behavior

This feature answers a question I've had since the first time I saw someone do BDD: What do you do when you want to specify the same behavior for multiple contexts?

[Subject("Calculating sales tax")]
public class when_an_item_is_a_kind_of_food : with_an_invoice_with_one_item
{
    Because of = () => invoice = new Invoice().WithSomeKindOf(Category.Food);
    Behaves_like<NoSalesTaxAdded> no_sales_tax_added;
}

[Subject("Calculating sales tax")]
public class when_an_item_is_a_kind_of_medical_supply : with_an_invoice_with_one_item
{
    Because of = () => invoice = new Invoice().WithSomeKindOf(Category.MedicalSupplies);
    Behaves_like<NoSalesTaxAdded> no_sales_tax_added;
}

[Behaviors]
public class NoSalesTaxAdded
{
    protected static Invoice invoice;

    It has_no_sales_tax_added = () =>
    {
        foreach (var item in invoice.Items)
            invoice.GetPostTaxValueFor(item).ShouldEqual(item.Value);
    };
}

In the samples that come with MSpec, there is an example of two implementations of the same interface, like a TypeFixture in MbUnit.

It seems like, in the applications I work on, I rarely run across a need to use this kind of test, but I do sometimes need RowTest-like tests, or, more often, factory driven tests - like to specify that for a certain set of contexts, there is some behavior. My example above is a lame attempt to illustrate this.

What's Next

That's kind of the technical view of things. Hopefully I've gotten your attention and you are git clone-ing MSpec in the background right now. I hope to post part 2 of this in a couple of days, with some examples of how I use MSpec in real code.

I should note that I am not comfortable posting my customized SFTS process template at this time. I need to discuss this with the folks at Conchango before taking that step.

• Slides – Supporting Scrum with Team System
• Slides – Agile Testing with Team System
• Code – RecipeBox sample code

Please be forgiving of the code, it isn’t stellar. Just what I was working on before I went into session :)

To everyone who attended my sessions, let me say, “Thank you”. I appreciated your feedback and enthusiasm. It was an honor.

I recently put together some notes for a presentation on cross site scripting, or XSS for short. I have decided to share some of the information, because I believe keeping a few thoughts in mind as we develop and test will go a long way when it comes to preventing attacks.

Cross Site Scripting – What is it?

Cross site scripting occurs when a web application gathers malicious data entered from a user, with or without negative intent. XSS can be achieved by exploiting locations in source code where users are able to input data, and the proper preventative measures have not been implemented to format and validate the inputted data. In other situations, session cookies and other sensitive data can be accessed by injecting malicious data and ultimately hijacking or impersonating a user’s account.

There are three main types of XSS according to Wikipedia, so I won’t bother rephrasing. Visit http://en.wikipedia.org/wiki/Cross-site_scripting for more information.

The most common technologies and languages used for XSS are JavaScript, VBScript, ActiveX, HTML, or Flash’s ActionScript. Not only do we need to protect our server code, but we need to think about our client code as well.

Prevention of Cross Site Scripting

The vast of majority of XSS attacks can be prevented by identifying the user input locations within the web application and ensuring the source code handling these has proper measures in place. From a developer’s perspective, this means ensuring all data inputted from a user is properly encoded to remove HTML and script markup to be replaced with text that all browsers can process.

A simple example in C# is to use the HttpServerUtility.HtmlEncode method to convert all HTML markup characters into their text equivalent. For example, if a user were to supply the input for a textbox with the following, “This is my <b>bolded text</b>.” The end result of the HtmlEncode method would result in the following, “This is my lt;bolded textgt;.” This is important because it removes HTML markup, which could be malicious. For example, “This is my text. <script>alert(‘This is an attack’);</script>.” This example is passing a JavaScript alert to open a modal popup on the screen to display to the user.

In addition to HTML inputted data encoded on the server, encoding data on the client can be equally important. JavaScript HTML elements can have two attributes, InnerHTML and InnerText. InnerText will render text, not HTML, so it is the safe option. InnerHTML can be used to inject an XSS attack because it can render user inputted HTML, including script. Ensure InnerHTML has the necessary string formatting to protect against this vulnerability.

Cookies are another vulnerability to XSS attacks. If any part of the website issues cookies and an XSS access point is discovered, it is now possible to steal cookies and private information from the application’s users. If the cookie can be accessed, so can the information with it. Users can be impersonated, and site credibility will be lost.

Encrypted web sites (SSL, HTTPS) are at risk just like their public counterparts. SSL sites appear to be protected, but it is possible to execute the same XSS attacks, they just happen over an encrypted connection.

To protect our web applications, we need to be aware of the XSS vulnerabilities common to attackers and place defensive measures to ensure user confidentiality and confidence. Without becoming an expert on XSS and security, it is possible to develop safe, reliable applications by understanding XSS and the vulnerabilities exposed by our applications.

What to Look for in Source Code

Execute a simple search in source code looking for certain keywords is a good starting point. Many of the XSS bugs I have seen reported could have been prevented with the simple measures. Ensure HTML input is properly encoded on the server using HtmlEncode. Ensure HTML input is properly formatted on the client using string.Format and InnerText.

In source code and wherever, look for the following vulnerabilities.

• InnerHTML
  • InnerText is not supported by all browsers but the two can be found together. Look for where the strings are originating and if they are properly formatted/encoded.
• SetInnerText()
• JavaScript’s Eval()
  • Don’t be Eval - http://24ways.org/2005/dont-be-eval
• Assigning of strings to page titles, control titles, ect.
  • Sometimes we take request object data and immediately process it and render it on the client.
  • Check the URL parameters passed in.
• The Request object
  • Request.Params
  • Request.Forms
  • Request.QueryString
• Using HtmlTextWriter or any variation
  • RenderBeginTag()
  • AddAttribute()
  • RenderEndTag()
  • HtmlWriter.Write()
• Cookies
  • Where are we using them and how are we handling them

Searching for these keywords within source will be a decent starting point for discovering XSS vulnerabilities

Microsoft Anti-Cross Site Scripting Library V3.0 Beta

Feel free to use a Microsoft API designed for XSS prevention within your code.

http://www.microsoft.com/downloads/details.aspx?FamilyId=051ee83c-5ccf-48ed-8463-02f56a6bfc09&displaylang=en

Closing Notes – because this topic can go on forever

There are tools to help assess if your site is vulnerable. Search for them online. Whether or not you think you need third party APIs to help you write defensive code is entirely up to you. You can always write the code yourself.

Cross-site scripting (XSS) can be damaging to a company’s credibility and can cause myriad undesirable effects for individual users. XSS is preventable. Familiarizing oneself with the smells of XSS is a valuable tool to posses as a developer and a tester. At a minimum, educate your developers and testers on the target hot-spots mentioned within this post.

References and Resources

http://en.wikipedia.org/wiki/Cross-site_scripting

http://www.cgisecurity.com/xss-faq.html

http://ha.ckers.org/xss.html

http://www.owasp.org/index.php/Cross_site_scripting

This post started to get a little long, so I won’t re-explain the concept.

Joshua Flanagan wrote a nice overview at his Los Techies blog: Auto mocking Explained.

My post is mainly here to describe the Unity version of an automocking container I threw together.

In Jan 2009 I blogged about my initial version of the Unity AutoMocker - Why am I blogging about it again?

I originally wrote the AutoMocker for the Unity container a year ago (Jan 2009, in Silverlight), and finally got around to placing the code up in the moq-contrib project in June of 2009.

I’m writing another post today in hopes to:

1. Get some feedback on how this little snippet of code should continue.
2. Give a little more how-to/example code
3. Describe some updates I made since I originally created it. 

Where can I get it?

This is one part where I’d appreciate some feedback.

I have two slightly different versions out there (currently).

I have one version at the ElegantCode repository where I was working on it, and the other I threw up at moq-contrib.

The core of the UnityAutoMockContainer is the same in both places, it’s how the tests are separated out that differ.

In the ElegantCode repository it’s an all in one self contained single file (that you can copy into your own test project(s)). You can then setup a single test in your own testing framework that runs all internal automocker tests (in case you need to modify it yourself, and don’t want to break any existing functionality). EX: test

[Test]
public void Should_run_all_UnityAutoMockContainer_internal_tests()
{
    Moq.AutoMocking.SelfTesting.UnityAutoMockContainerFixture
        .RunAllTests(Console.WriteLine);
}

I kind of like this format as it makes it easy to port between test libraries. Can’t say I like having the tests in the same file as the core, but it certainly is not a large chunk of code (so far) so it’s relatively small to maintain and definitely easier to manage as a single .cs file than another assembly (which would have to be version dependent on both Unity and Moq).

The moq-contrib is definitely where I think this helper should end up (and it is there). I just happened to break the tests out into the Silverlight test project and the core is alone in a file.

It’s current state isn’t as easy to copy to a test library (Silverlight/Desktop/Unity 1.2/Unity 2.0) as the one at ElegantCode. What does anyone think? Should I put them all together in one file?

However it ends up (1. all in one file or two (1 test) (1 core)) it will continue to be maintained on the moq-contrib project.

What is the high level API of the container?

It’s pretty simple, (currently) there are four methods on the container.

Two for registering items with the container. Say you want to register an already created instance, or say you want to map an interface to a concrete class and _not_ have the container generate mocks automatically for special cases.

And two for pulling items out of the container. Whether you want a instance of T or a Mock<T>, it gives you ways to retrieve both.

How can I setup my own registrations with the container?

Say I don’t want to have the container generate mocks for specific items and I want to supply specific configuration to the UnityContainer.

public UnityAutoMockContainer RegisterInstance<TService>(TService instance)

public UnityAutoMockContainer Register<TService, TImplementation>()
                where TImplementation : TService

Note: both of these registration methods return the container itself so you can fluently stack registration. EX:

AutoMockContainer
    .Register<IServiceA, ServiceA>()
    .Register<IServiceB, ServiceB>();

Let me know: I haven’t tested or played around with how this automocking container deals with any container specific xml configuration… So although I don’t think you should probably have that in a test assembly (stuff happens). Let me know if there are any issues.

How do I get items out of the container?

First is the Resolve<T>(). It will pull an item T out of the container. (Creating it if not already existing)

public T Resolve<T>()

When T is an interface Resolve<T> (unless you setup registration specifically with the container) should return basically “(new Mock<T>()).Object”

When T is a concrete Class, the container should return an instance of T and any of it’s dependencies will be satisfied by mocks. (Note that T will not be any sort of mocked instance of T, unless you used the GetMock<T> as described below first)

public Mock<T> GetMock<T>() where T : class

When T is an interface GetMock<T> should return basically “(new Mock<T>())”

When T is a concrete Class, the container should return a new Mock<T>() and any of it’s dependencies will be satisfied by mocks.

How do I use the UnityAutoMockContainer?

It’s pretty basic, you first create an instance of the UnityAutoMockContainer, and from there you can ask it for mocks of an (Interface, Class, or Abstract Class).

If you request an instance of a concrete class, or abstract class, the UnityAutoMockContainer will stuff mocks in for any constructor dependencies of your concrete class (if it can). You can then request from the container those same dependencies one at a time and either apply mocking setups or verifications.

NOTE: Anything the container creates will live as a singleton instance in the container. So any other requests from the container will always return the originally created instance. Therefore, each distinct scenario in a test suite should have their own instances of the container.

Below his an example of how you can leverage the container in some tests. Given this base fixture class…

public class FixtureBase
{
    private readonly UnityAutoMockContainer _autoMockContainer = new UnityAutoMockContainer();

    protected UnityAutoMockContainer AutoMockContainer
    {
        get { return _autoMockContainer; }
    }

    [TestFixtureSetUp]
    public void SetupContext_ALL()
    {
        Before_all_tests();
        Because();
    }

    [TestFixtureTearDown]
    public void TearDownContext_ALL()
    {
        After_all_tests();
    }

    protected virtual void Before_all_tests()
    {
    }

    protected virtual void Because()
    {
    }

    protected virtual void After_all_tests()
    {
    }
}

If I were given the following system to test.

public interface IServiceA { void RunA(); }
public interface IServiceB { void RunB(); }

public class TestComponent
{
    public TestComponent(IServiceA serviceA, IServiceB serviceB)
    {
        ServiceA = serviceA;
        ServiceB = serviceB;
    }

    public IServiceA ServiceA { get; private set; }
    public IServiceB ServiceB { get; private set; }

    public void RunAll()
    {
        if (!HowDidItGo())
            return;
        ServiceA.RunA();
        ServiceB.RunB();
    }

    public virtual bool HowDidItGo()
    {
        // some really nasty untestable code
        return true;
    }
}

The below example demonstrates simply verifying some behavior on the mocked dependencies of the system under test.

[TestFixture]
public class Example__how_to_pull_items_from_the_UnityAutoMockContainer_when_verifying_behavior_after_an_action_was_taken 
    : FixtureBase
{
    private TestComponent _testComponent;

    protected override void Before_all_tests()
    {
        base.Before_all_tests();
        _testComponent = AutoMockContainer.Resolve<TestComponent>();
    }

    protected override void Because()
    {
        _testComponent.RunAll();
    }

    [Test]
    public void Should_run_ServiceA_RunA()
    {
        AutoMockContainer
            .GetMock<IServiceA>()
            .Verify(v => v.RunA(), Times.Once());
    }

    [Test]
    public void Should_run_ServiceB_RunB()
    {
        AutoMockContainer
            .GetMock<IServiceB>()
            .Verify(v => v.RunB(), Times.Once());
    }
}

Next, you may have noticed that the system under test had a complicated internal method (that may not necessarily be testable). You can use the AutoMocker to create the system under test as a Mock itself, so we can override some of the behavior. Here’s how you could quickly do that.

Aside: I’m not saying this is a good practice or aids in good component design, just saying it’s possible

[TestFixture]
public class Example__how_to_use_the_UnityAutoMockContainer_to_override_a_method_on_the_SystemUnderTest_to_test_a_certain_behavior
    : FixtureBase
{

    private TestComponent _testComponent;

    protected override void Before_all_tests()
    {
        base.Before_all_tests();
        var mockTestComponent = AutoMockContainer.GetMock<TestComponent>();

        mockTestComponent
            .Setup(s => s.HowDidItGo())
            .Returns(false);

        _testComponent = mockTestComponent.Object;
    }

    protected override void Because()
    {
        _testComponent.RunAll();
    }

    [Test]
    public void Should_run_ServiceA_RunA()
    {
        AutoMockContainer
            .GetMock<IServiceA>()
            .Verify(v => v.RunA(), Times.Never());
    }

    [Test]
    public void Should_run_ServiceB_RunB()
    {
        AutoMockContainer
            .GetMock<IServiceB>()
            .Verify(v => v.RunB(), Times.Never());
    }
}

It’s amazing how much redundant test setup code this little helper has saved me in my tests. I hope others can find some use with this as well.