First Task: MembershipProvider.CreateUser

There is some logic involved in maintaining the in-memory information, and I certainly don't want to have to run a web application to test the functionality as I'm building it, so the first thing is to create a ".Test" assembly. 

My first test for creating a MembershipUser looked something like this:

[Test]
public void CreateUser()
{
    // this is what we're testing:
    var provider = new VirtualMembershipProvider();
    
    // creation of all of these args omitted for brevity..
    var user = provider.CreateUser(...);
    
    // verify that the MembershipUser is valid..
    Assert.AreEqual(user.UserName, userName); // etc.etc.etc.
}

And the implementation of VirtualMembershipProvider.CreateUser():  (obviously I'm leaving out some unimportant details..)

public override MembershipUser CreateUser(...)
{
    // MembershipUser takes crazy big number of args..
    MembershipUser user = new MembershipUser(...);
    // TODO: put that user object somewhere for later access..
    status = MembershipCreateStatus.Success;
    return user;
}

Can't get much simpler, right? 

First Issue - Arbitrary Dependency

Running the test gives an exception from the MembershipUser constructor: "System.ArgumentException : The membership provider name specified is invalid." So, we jump over to Reflector to see what's going on:

if ((providerName == null) || 
    (Membership.Providers[providerName] == null))
{
  throw new ArgumentException(...);
}

MembershipUser has a dependency on Membership.Providers.  This is because MembershipUser is not just a data container, but breaks the Single Responsibility Principle (SRP) and has methods like Update() as well.  But, whatever.  Looks like all I've got to do is add my VirtualMembershipProvider into that Membership.Providers collection, and we'll be set.

Next Issue - Arbitrary ReadOnly-ness

I put "Membership.Providers.Add()" into the test, to see what happens.  Running the test gives me a new exception: in ProviderCollection.Add() - "System.NotSupportedException : Collection is read-only."  Argh!  Back to Reflector!  Here's what ProviderCollection.Add() looks like (more or less):

public virtual void Add(ProviderBase provider)
{
    if (this._ReadOnly)
        throw new NotSupportedException(...);
    // some other guard clauses...
    this._Hashtable.Add(provider.Name, provider);
}

So all I've got to do is call ".IsReadOnly = false" and... ha ha jokes on me.  ProviderCollection has a SetReadOnly() method, but no public way to switch readonly-ness off.  Presumably there's some really good reason for making things difficult with this totally artificial wall that they put in our path.

So, we fall back to the tool of last resort: reflection to get that private _ReadOnly field and set it to false.  Now we can register our provider into the ProviderCollection.  But, what an ugly hack, for seemingly no reason.

One more thing lacking: before the ProviderCollection will accept a Provider, it checks to see if the Provider has been initialized properly.  So we need a call to provider.Initialize() which sets some internal state on the provider.

(Note: by this point, we actually have a fair amount of initialization code here, and its getting complicated.  So this code was moved into its own class & tests - I've left that part out to be more concise.)

More or less, we've got this code to set up our MembershipProvider, outside of the official procedures:

public static void Initialize(MembershipProvider provider, 
                              string providerName)
{
    provider.Initialize(providerName, null);
    // grabs a cached FieldInfo instance and sets it appropriately.
    // note this would affect all Membershp providers...
    AllowNewProviders = true;
    Membership.Providers.Add(provider);
}

And now, our CreateUser() test passes and we can get back to work on the REAL problem. 

Conclusions

• Don't put arbitrary roadblocks in your framework.  You have no idea how somebody will need to use (and abuse) it.
• Strive to keep your code decoupled.  Always a good idea no matter what you're working on.
• This is "running with scissors:" I wouldn't propose subverting the Provider model with this sort of hackery for code that you wanted to use in production, at least not with much more testing and consideration.  There might be (and probably is) a really good reason for that _ReadOnly flag, and we just broke it..
• And to bring us back to the first point: framework developers should provide the "default safe" implementation with that _ReadOnly flag, but then at least provide a way to cleanly get around the safety mechanism, for those of us who are willing to accept the risk.

So, ASP.NET, thanks for the offer of holding my hand through every step of the way, but instead how about you just get out of my way and let me get my work done, kthxbai.

   1: [TestFixture]

   2: public class StackFixture : AbstractBaseFixture

   3: {

   4:     private Stack stack;

   5: 

   6:     [SetUp]

   7:     public void SetUp()

   8:     {

   9:         stack = new Stack();

  10:     }

  11: 

  12:     [Test]

  13:     public void Empty()

  14:     {

  15:         Log.Info("Starting Empty test");

  16:

  17:         Assert.IsTrue(stack.IsEmpty);

  18:

  19:         Log.Info("Ending Empty test");

  20:     }

  21: 

  22:     [Test]

  23:     public void PushOne()

  24:     {

  25:         Log.Info("Starting PushOne test");

  26: 

  27:         stack.Push("first element");

  28:         Assert.IsFalse(stack.IsEmpty, "After Push, IsEmpty should be false.");

  29: 

  30:         Log.Info("Ending PushOne test");

  31:     }

  32: 

  33:     [Test]

  34:     public void Pop()

  35:     {

  36:         Log.Info("Starting Pop test");

  37: 

  38:         stack.Push("first element");

  39:         stack.Pop();

  40:         Assert.IsTrue(stack.IsEmpty, "After Push - Pop, IsEmpty should be true.");

  41: 

  42:         Log.Info("Ending Pop test");

  43:     }

  44: 

  45:     [Test]

  46:     [ExpectedException(typeof(InvalidOperationException))]

  47:     public void PopEmptyStack()

  48:     {

  49:         Log.Info("Starting PopEmptyStack test");

  50: 

  51:         stack.Pop();

  52: 

  53:         Log.Info("Ending PopEmptyStack test");

  54:     }

  55: }

   1: public void TestMethod(string beforeMessage, string afterMessage, Action action)

   2: {

   3:     // before

   4:     Log.Info(beforeMessage);

   5:

   6:     // invoke our method

   7:     action();

   8:

   9:     // after

  10:     Log.Info(afterMessage);

  11: }

   1: [Test]

   2: public void Pop()

   3: {

   4:     Log.Info("Starting Pop test");

   5: 

   6:     stack.Push("first element");

   7:     stack.Pop();

   8:     Assert.IsTrue(stack.IsEmpty, "After Push - Pop, IsEmpty should be true.");

   9: 

  10:     Log.Info("Ending Pop test");

  11: }

   1: [Test]

   2: public void Pop()

   3: {

   4:     TestMethod("Starting Pop test", "Ending Pop test",

   5:                delegate

   6:                    {

   7:                        stack.Push("first element");

   8:                        stack.Pop();

   9:                        Assert.IsTrue(stack.IsEmpty, "After Push - Pop, IsEmpty should be true.");

  10:                    });

  11: }

   1: [Serializable]

   2: public sealed class LoggingMethodInvocationAspect : OnMethodInvocationAspect

   3: {

   4:     private ILogger log;

   5: 

   6:     public LoggingMethodInvocationAspect(ILogger logger)

   7:     {

   8:         log = logger;

   9:     {

  10: 

  11:     public override void OnInvocation(MethodInvocationEventArgs eventArgs)

  12:     {

  13:         // before

  14:         log.Info("OnInvocation Before proceed");

  15: 

  16:         // invoke

  17:         eventArgs.Proceed();

  18: 

  19:         // after

  20:         log.Info("OnInvocation After proceed");

  21:     }

  22: }

   1: [assembly: ClassLibrary.SampleInterfaces.LoggingMethodInvocationAspect(

   2:     AttributeTargetAssemblies = "ClassLibrary.UnitTesting.Sandbox",

   3:     AttributeTargetTypes = "ClassLibrary.UnitTesting.Sandbox.MathService",

   4:     AttributeTargetMembers = "Test*")]

   1: [assembly: ClassLibrary.SampleInterfaces.LoggingMethodInvocationAspect(

   2:   AttributeTargetAssemblies = "ClassLibrary.UnitTesting.Sandbox",

   3:   AttributeTargetTypes = "ClassLibrary.UnitTesting.Sandbox.MathService",

   4:   AttributeTargetMembers = "Test*")]

   5:

   6: [TestFixture]

   7: public class StackFixture

   8: {

   9:     private Stack stack;

  10: 

  11:     [SetUp]

  12:     public void SetUp()

  13:     {

  14:         stack = new Stack();

  15:     }

  16: 

  17:     [TearDown]

  18:     public void TearDown(){}

  19: 

  20:     [Test]

  21:     public void TestEmpty()

  22:     {

  23:         Assert.IsTrue(stack.IsEmpty);

  24:     }

  25: 

  26:     [Test]

  27:     public void TestPushOne()

  28:     {

  29:         stack.Push("first element");

  30:         Assert.IsFalse(stack.IsEmpty, "After Push, IsEmpty should be false.");

  31:     }

  32: 

  33:     [Test]

  34:     public void TestPop()

  35:     {

  36:         stack.Push("first element");

  37:         stack.Pop();

  38:         Assert.IsTrue(stack.IsEmpty, "After Push - Pop, IsEmpty should be true.");

  39:     }

  40: 

  41:     [Test]

  42:     [ExpectedException(typeof(InvalidOperationException))]

  43:     public void TestPopEmptyStack()

  44:     {

  45:         stack.Pop();

  46:     }

  47: }

Where it led me was to re-investigate Partial Mocks in Rhino Mocks.  My original misunderstanding of Partial Mocks was that they would only mock Abstract Classes.  A partial mock will mock ANY class -- but only the Partial mock will only mock abstract methods.  That small misunderstanding has caused me to loose untold amount of hair and good will towards all men.

So I'm going to re-implement my class methods.  Here you go:

public class MyClass
{
    public int Foo()
    {
        // stuff happens here
        int i = Bar();
        // do more stuff here    
        return i + 5;
    }
    public virtual int Bar()
    {
       // do some logic
       return 1;
    }
}

A few changes here.  First, I removed the delegate and renamed BarInternal back to Bar.  Second, I marked the Bar method as virtual. 

They key point about a virtual method is that you can provide an implementation, and then a inherited class can completely override that method.  That is what the Partial Mock is allowing us to do.

So how do I write my tests?  If you don't like using Rhino Mocks you do this:

[Test]
public void FooTest()
{
    int expected = 7;
    int result = 0;
    MockRepository mock = new MockRepository();
    MyClass c = mock.PartialMock<MyClass>();

    using (mock.Record())
    {
        Expect.Call(c.Bar()).Return(2);
    }
    using (mock.Playback())
    {
        result = c.Foo();
    }

    Assert.AreEqual(expected, result);
}

Obviously, now my test is referencing the Rhino Mocks library.  The variable mock is the Mock Repository.  Now the big change is that I don't create MyClass directly, but through the Rhino Mocks PartialMock method.

Next, I tell the mock repository to expect a call to c.Bar, and when called return 2.  That is what is happening in the using (mock.Record()) section of the code.  Then, in the mock.Playback section, I call Foo().

One other quick note, if we were to rewrite Foo such that it no longer called Bar this test will fail.  The Expect.Call part tell the mock repository that the method Bar will be called, and if it isn't there is a problem.  There are ways around that as well, but that is a topic for another day.

Where does that leave us now?  Aside from the odd "virtual" keyword thrown into our production code, this is the code as you would have originally written it, even without TDD.  I don't like making API changes just to satisfy testing, but I am very OK with this change.

But what about that new kid on the block?  You know, Moq.

I still love Rhino Mocks, but I can't help but want to play with a new toy.  So here is the same thing, but in Moq:

[Test]
public void Foo_moq_test()
{
    Mock<MyClass> mock = new Mock<MyClass>();
    mock.Expect(x => x.Bar()).Returns(2);

    MyClass c = mock.Object;
    int result = c.Foo();
    Assert.AreEqual(7, result);
}

So as you should be able to see, Moq is a very different animal than RhinoMocks.  There is no Record or Playback (the web site calls those confusing, I disagree, but still), and the Expect happens with a anonymous delegate (in the form of the Lambda Expression "x => x.Bar()" where x is of type MyClass).

The cool part is that you can get the same results with less code using Moq.  That has been the main advantage all along.  My informal testing also reveals that Moq is just a hair faster than Rhino Mocks (but not fast enough to warrant switching frameworks).

The problem

You have two methods (Foo and Bar), and Foo calls method Bar.  It will look like this:

public int Foo()
{
    // stuff happens here
    int i = Bar();
    // do more stuff here
    return i + 5
}

public int Bar()
{
   // do some logic
   return 1;
}

Now you need to test both methods.  Bar can be easily tested like this (this should work for NUnit and MBUnit tests -- assuming both methods exist in a class call MyClass):

[Test]
public void Bar_Test()
{
    MyClass c = new MyClass();
   int result = c.Bar();
   Assert.AreEqual(1, result);
}

Now we test Foo:

[Test]
public void Foo_Test()
{
   MyClass c = new MyClass();
   int result = c.Foo();
   Assert.AreEqual(6, result);
}

Here is where we have an issue.  What if the result of Bar changes?  That will break the test.  So now we have a brittle test.  Any time Bar changes, we have to change all of the Bar tests, but also the Foo tests, so we have added complexity to our tests as well.  Now if Foo (or Bar) was in a separate class, this wouldn't be an issue, but they are in the same class.  And as much as I like small classes, this seems too trivial to split up (even in the context of an extremely trivial example).

The Solution

What I would like to do is Mock the method Bar.  You can do that with a delegate.

Without really getting into what a delegate is, I will just show the code.  So here are my two methods, with a delegate added in for good measure.

public delegate int BarDelegate();

public BarDelegate Bar;

public MyClass()
{
    Bar = BarInternal;
}

public int Foo()
{
    // stuff happens here
    int i = Bar();
    // do more stuff here    
    return i + 5;
}

public int BarInternal()
{
   // do some logic
   return 1;
}

OK, here is what I did:

1. Renamed Bar to BarInternal
2. BarDelegate delegate
3. Created a variable named Bar to point to the method BarInternal
4. Created a constructor to hook up Bar to BarInternal.

Now all of my code can still use the method Bar just like it was there, but in actuality it is calling BarInternal.  I have now created one layer of indirection to my method Bar so it can now be mocked and tested.

Here is my new test for Foo:

[Test]
public void FooTest()
{
    MyClass c = new MyClass()
    c.Bar = BarMethodForTest;
    int result = target.Foo();
    Assert.AreEqual(7, result);
}

private int BarMethodForTest()
{
    return 2;
}

So what is new with the test is the BarMethodForTest that is passed to c.Bar and I have coded BarMethodForTest to always return 2.  When I set c.Bar to my new method, BarInternal (the default method) is no longer called.

Actually, if I wanted to I could simplify this further by setting c.Bar with an anonymous delegate like this:

[Test]
public void FooTest()
{
    MyClass c = new MyClass()
    c.Bar = delegate() { return 2; }
    int result = target.Foo();
    Assert.AreEqual(7, result);
}

Stepping Back

OK, take a step back and look at this again with a critical eye.  Have I really solved the problem?   Yes and no.  The real problem was that my methods were too complex to simply test.  Now my methods are simple to test, but the code is complex to read.  All I've done is shifted the complexity from one class to the other.  A better solution would to have created another class and further abstracted out the logic.

At the same time, my class is not overly burdened by the change either.  In lieu of a real refactoring, I do consider this a viable solution to the problem.  So by all means do this -- but make sure you are out of alternatives first.

First Task: MembershipProvider.CreateUser

There is some logic involved in maintaining the in-memory information, and I certainly don't want to have to run a web application to test the functionality as I'm building it, so the first thing is to create a ".Test" assembly. 

My first test for creating a MembershipUser looked something like this:

[Test]
public void CreateUser()
{
    // this is what we're testing:
    var provider = new VirtualMembershipProvider();
    
    // creation of all of these args omitted for brevity..
    var user = provider.CreateUser(...);
    
    // verify that the MembershipUser is valid..
    Assert.AreEqual(user.UserName, userName); // etc.etc.etc.
}

And the implementation of VirtualMembershipProvider.CreateUser():  (obviously I'm leaving out some unimportant details..)

public override MembershipUser CreateUser(...)
{
    // MembershipUser takes crazy big number of args..
    MembershipUser user = new MembershipUser(...);
    // TODO: put that user object somewhere for later access..
    status = MembershipCreateStatus.Success;
    return user;
}

Can't get much simpler, right? 

First Issue - Arbitrary Dependency

Running the test gives an exception from the MembershipUser constructor: "System.ArgumentException : The membership provider name specified is invalid." So, we jump over to Reflector to see what's going on:

if ((providerName == null) || 
    (Membership.Providers[providerName] == null))
{
  throw new ArgumentException(...);
}

MembershipUser has a dependency on Membership.Providers.  This is because MembershipUser is not just a data container, but breaks the Single Responsibility Principle (SRP) and has methods like Update() as well.  But, whatever.  Looks like all I've got to do is add my VirtualMembershipProvider into that Membership.Providers collection, and we'll be set.

Next Issue - Arbitrary ReadOnly-ness

I put "Membership.Providers.Add()" into the test, to see what happens.  Running the test gives me a new exception: in ProviderCollection.Add() - "System.NotSupportedException : Collection is read-only."  Argh!  Back to Reflector!  Here's what ProviderCollection.Add() looks like (more or less):

public virtual void Add(ProviderBase provider)
{
    if (this._ReadOnly)
        throw new NotSupportedException(...);
    // some other guard clauses...
    this._Hashtable.Add(provider.Name, provider);
}

So all I've got to do is call ".IsReadOnly = false" and... ha ha jokes on me.  ProviderCollection has a SetReadOnly() method, but no public way to switch readonly-ness off.  Presumably there's some really good reason for making things difficult with this totally artificial wall that they put in our path.

So, we fall back to the tool of last resort: reflection to get that private _ReadOnly field and set it to false.  Now we can register our provider into the ProviderCollection.  But, what an ugly hack, for seemingly no reason.

One more thing lacking: before the ProviderCollection will accept a Provider, it checks to see if the Provider has been initialized properly.  So we need a call to provider.Initialize() which sets some internal state on the provider.

(Note: by this point, we actually have a fair amount of initialization code here, and its getting complicated.  So this code was moved into its own class & tests - I've left that part out to be more concise.)

More or less, we've got this code to set up our MembershipProvider, outside of the official procedures:

public static void Initialize(MembershipProvider provider, 
                              string providerName)
{
    provider.Initialize(providerName, null);
    // grabs a cached FieldInfo instance and sets it appropriately.
    // note this would affect all Membershp providers...
    AllowNewProviders = true;
    Membership.Providers.Add(provider);
}

And now, our CreateUser() test passes and we can get back to work on the REAL problem. 

Conclusions

• Don't put arbitrary roadblocks in your framework.  You have no idea how somebody will need to use (and abuse) it.
• Strive to keep your code decoupled.  Always a good idea no matter what you're working on.
• This is "running with scissors:" I wouldn't propose subverting the Provider model with this sort of hackery for code that you wanted to use in production, at least not with much more testing and consideration.  There might be (and probably is) a really good reason for that _ReadOnly flag, and we just broke it..
• And to bring us back to the first point: framework developers should provide the "default safe" implementation with that _ReadOnly flag, but then at least provide a way to cleanly get around the safety mechanism, for those of us who are willing to accept the risk.

So, ASP.NET, thanks for the offer of holding my hand through every step of the way, but instead how about you just get out of my way and let me get my work done, kthxbai.