SpeakENG

Martin Fowler has a great post entitled Mocks Aren't Stubs. Go ahead and read/skim through that if you haven't. Of the two categories of TDDers he defines, I am definitely a mockist. That is, I almost always "use a mock for any object with interesting behavior". I do use Mocks and Stubs, but those stubs are generally just Mocks set up to be stubs (as it's easier than stubbing a class myself.) That said, I do have a few ground rules for when I write tests with Rhino Mocks that sort fall into the whole one assertion per test topic and the mocks vs. stubs thing. Here they are:

1. Name TestMethods MethodOrPropertyName_Scenario_ExpectedResult. I stole this from someone, but I can't remember who. If you know what post that was, let me know so I can link it. An example is: CalculateCost_WhenProductIsNull_ThrowsException. I just think this makes your intent very clear and readable.
2. Never use _mocks.Ordered() unless you are actually testing the order in which something is called... and if you are, test only that!
3. Unless you're testing that something gets called once and only once (expensive method? caching?), use Repeat.Any(). Who cares if it gets called again?
4. Prefer DynamicMock over CreateMock (standard mocks). Here's an example. You're testing that your controller sets FirstName on a view. You write that test and implement the feature. Two days later you need to add EmailAddress to that view, so you write your test to ensure that it is added. You implement it and run your tests... now, if you used a standard mock, your original FirstName test would fail! With a DynamicMock however, you have no tests to "fix" (tests should rarely need to be fixed because you added something to the class that has no bearing on the originally tested scenario)
5. Don't use VerifyAll. What!?!? That's right, half the time I use Verify(someMock) and the other half I don't even Verify anything (as I can verify the result of a method called). Your tests should be complete enough that it shouldn't matter if ObjectA called ObjectB as long as ObjectA gives you the correct result.

Remember, Verification, Ordering, setting a fixed # of repeats, requiring every method/property to be "expected", etc, are all Assertions. I'm not steadfast on the whole one assertion per test thing, as sometimes a few assertions make sense. As long as you at least think about what your test would be named if you put every assertion in the method name of the test, I think that a lot of these rules would make more sense.... Would you rather diagnose a break in SomeMethod_WhenSomeObjectIsGreen_CallsFooTwiceThenCallsBarWithResultOfFoo
OnceThenSetsColorAndShapeAndResultOfFoo() or SomeMethod_WhenSomeObjectIsGreen_SetsColor()? :)

Roy Osherove brings up several good points with regards to the preached design methodology of old and the new testable design some of us have come to know and love lately.

I think that TDD really helps to eliminate a large number of these issues. If you test everything yourself, then inherently your API is testable. Unfortunately, as Jonathan Cogley points out, TDD is not yet mainstream.

A nice side effect of having a testable API or application is that often times your code is also extensible. The thing that blocks it from being fully testable and extensible are those darn sealed and internal keywords, and of course, not making things virtual that really should be. Even open source projects are guilty of not having testable or extensible enough APIs. Yes, Castle MonoRail provides AbstractMRTestCase, but that actually uses ASP.NET and is way more heavy than I like.

Here is our base class for Controller Tests. This allows you to unit test nearly every aspect of your controller, without ever hitting ASP.NET. Notice the lovely and necessary use of reflection? In order to mock the context, you'll want to call InitializeController and pass it the controller you're testing, but be sure to do it in your _mocks.Unordered block (we almost ALWAYS use mocks.Unordered... it makes tests more readable and ensures that you're tests aren't too tightly coupled with your implementation, but that's the subject for another post.)

  public class EleutianControllerTests
  {
    #region Constants
    private const string ApplicationPhysicalPath = "Q:\\PhysicalPath";
    #endregion

    #region Member Data
    protected string _virtualDirectory = String.Empty;
    protected MockRepository _mocks;
    protected IControllerServices _controllerServices;
    protected IRailsEngineContext _context;
    protected IRequest _request;
    protected IResponse _response;
    protected IServerUtility _serverUtility;
    protected IDictionary _session;
    protected Flash _flash;
    protected NameValueCollection _parameters;
    #endregion

    #region Test Setup and Teardown Methods
    [SetUp]
    public virtual void Setup()
    {
      _mocks = new MockRepository();
      _context = _mocks.CreateMock<IRailsEngineContext>();
      _request = _mocks.DynamicMock<IRequest>();
      _response = _mocks.DynamicMock<IResponse>();
      _serverUtility = _mocks.DynamicMock<IServerUtility>();
      _session = _mocks.DynamicMock<IDictionary>();
      _flash = new Flash();
      _parameters = new NameValueCollection();
    }

    protected void InitializeController(Controller controller, string areaName, string controllerName, string actionName)
    {
      BindingFlags bindingFlags = BindingFlags.FlattenHierarchy | BindingFlags.Instance | BindingFlags.NonPublic |
                                  BindingFlags.InvokeMethod;

      MethodInfo method = controller.GetType().GetMethod("InitializeControllerState", bindingFlags);
      method.Invoke(controller, new object[] { areaName, controllerName, actionName });

      FieldInfo field = controller.GetType().GetField("context", bindingFlags);
      field.SetValue(controller, _context);

      field = controller.GetType().GetField("serviceProvider", bindingFlags);
      field.SetValue(controller, _context);

      InitializeRailsContext(areaName, controllerName, actionName);
    }

    protected void InitializeRailsContext(string areaName, string controllerName, string actionName)
    {
      Expect.Call(_context.UrlInfo).Return(
        new UrlInfo("eleutian.com", "www", _virtualDirectory, "http", 80,
                    Path.Combine(Path.Combine(areaName, controllerName), actionName), areaName, controllerName,
                    actionName, "rails")).Repeat.Any();
      Expect.Call(_context.GetService(typeof(IUrlBuilder))).Return(new DefaultUrlBuilder()).Repeat.Any();
      Expect.Call(_context.Server).Return(_serverUtility).Repeat.Any();
      Expect.Call(_context.Flash).Return(_flash).Repeat.Any();
      Expect.Call(_context.ApplicationPath).Return("/").Repeat.Any();
      Expect.Call(_context.Request).Return(_request).Repeat.Any();
      Expect.Call(_context.Response).Return(_response).Repeat.Any();
      Expect.Call(_context.ApplicationPhysicalPath).Return(ApplicationPhysicalPath).Repeat.Any();
      Expect.Call(_request.Params).Return(_parameters).Repeat.Any();
      Expect.Call(_context.Session).Return(_session).Repeat.Any();
    }
    #endregion
  }

Oh, and back to the original point of the post. Please, please don't mark things internal or sealed unless you have a very good reason to do it. And no, I don't think that "We can't afford to support it" is a good enough reason. Also, "We're afraid the user might break something" is DEFINITELY not a good enough reason. We know what we're getting into when we extend APIs... we're all developers here.

I've been writing a lot of tests lately because our code coverage isn't up to where we'd like it. NCover+NCoverExplorer is a pretty awesome and while it does have its quirks it has been incredibly useful. A lot of my adventures in writing tests is creating tons of RhinoMocks so that I can pass them to constructors and that sort of thing. So I got a strange idea, and I'm not sure how I feel about it necessarily and figured I'd propose it to all of you out there and get your thoughts.

Basically, 99% of the time in a services unit test, all the interfaces passed to the service will be mocks, so we end up with lots of functions that look like this:

[SetUp]
public void Setup()
{
  _service1 = _mocks.CreateMock<IService1>();
  _service2 = _mocks.CreateMock<IService2>();
  _service3 = _mocks.CreateMock<IService3>();
  _serviceWeAreTesting = new DefaultServiceWeAreTesting(_service1, _service2, _service3);
}

If we do this a lot for DefaultServiceWeAreTesting, it's often refactored to a single location. All in all, it can be very repetitive to create all the mocks. So, as an experiment I decided to leverage the power of the IoC container, in our case Windsor, to take care of a lot of the mundane for me. In the end I end up with this code:

[SetUp]
public void Setup()
{
  _mocks = new MockRepository();
  _container = new AutoMockingContainer(_mocks);
  _service = _container.Create<DefaultServiceWeAreTesting>();
}

AutoMockingContainer is simply a WindsorContainer with a custom facility and dependency resolver that supplies a RhinoMock for any interface that is resolved. We've also moved the setup code into a base class AutoMockingTests that has the container and mock repository. We can then write code that uses the mocks from the container:

[Test]
public void DoWork_Always_AsksOtherServices()
{
  using (_mocks.Unordered())
  {
    _container.Get<Service1>().DoWork();
    _container.Get<Service2>().DoWork();
    _container.Get<Service3>().DoWork();
  }
  _mocks.ReplayAll();
  _service.DoWork();
  _mocks.VerifyAll();
}

Of course, you don't have to always do the Get call on the container, you can do that in the Setup and use member variables, etc... the point is, the mocked services are created for us. We can also mark other types so that they aren't tested, and take advantage of the IoC and injection that we use in our application to speed up writing and maintaining tests. The implementation I've uploaded allows you to associate a particular strategy with service dependencies. They are:

• StubbedStrategy: A mock will be created, then for each property a GetValue expectation (with Repeat.Any) will be added to return a value for that property. The value will be retrieved like any other dependency (it's strategy will be gotten, and the value from that)
• DynamicStrategy (default): A DynamicMock will be created for the dependency.
• StandardStrategy: A standard mock from CreateMock.
• NonMockedStrategy: Automatically set for any service that is registered normally with the container - a standard container resolve.

So, pros and cons? To get things started:

Pros

1. Can be easier to maintain and write tests. Adding a dependency or changing the constructor breaks tests in ways that the production environment can usually handle just fine.
2. Automatic testing the services construction via the IoC container.

Cons

1. Speed/peformance? Does making the container such an integral part of the test fixtures hurt performance? Setup has to be longer when we're creating the container the way we are. Does this matter? Only as long as the time saved when writing tests is larger than the time it takes to run them, which I'm sure is the case...

What do you think? So far we really like the idea, or at least think it's interesting. Here are the sources:

Source and Binaries

I'm pleased to announce that I've committed Castle.Tools.CodeGenerator into the CastleContrib repository. What's in trunk also includes some patches posted on the mailing list by Chris Ortman and some other suggestions. It also includes some bug fixes I made. We've deleted the code generator from our repository, so any changes we make will be to the castle repository. Eleutian.Tools.CodeGenerator is no more, long live Castle.Tools.CodeGenerator!

I spent yesterday and today refactoring the code for the Controller Action/View map generator tool. I made some improvements, wrote some tests and I'm pleased to announce the first release. I saw Brian had implemented his as an MsBuild task and I liked that idea, so that's how ours runs now. First, things aren't as "drop in and go" as I would like because it's still evolving in and around our, already large, code base. It's my hope that over time the tool evolves as peoples needs change, etc... we can add some more configuration, that sort of thing. I'm more than willing to hear suggestions and such. Anway, here we go...

So in order to get yourself up and running, you'll need to do a few things. First, you'll need to add the task to your MsBuild. Simply open your csproj and add the following:

<UsingTask TaskName="Eleutian.Tools.CodeGenerator.MsBuild.GenerateMonoRailSiteTreeTask" AssemblyFile="Eleutian.Tools.CodeGenerator.dll" />
<ItemGroup>
  <ViewSources Include="../YourViewsDirectory/**/*.brail">
    <InProject>false</InProject>
  </ViewSources>
</ItemGroup>
<ItemGroup>
  <ControllerSources Include="Controllers/**/*.cs">
    <InProject>false</InProject>
  </ControllerSources>
</ItemGroup>
<Target Name="BeforeBuild" Inputs="@(Compile)" Outputs="$(ProjectDir)\SiteMap.generated.cs">
  <GenerateMonoRailSiteTreeTask File="SiteMap.generated.cs" Namespace="YourNamespace.SiteMap" ControllerSources="@(ControllerSources)" ViewSources="@(ViewSources)">
  </GenerateMonoRailSiteTreeTask>
</Target>

You'll notice a few things in here. ViewSources is just the collection of view files (be it .vm or .brail, etc..). It will use the paths of those files to add the View nodes into the map. ControllerSources is the C# source files for your controllers only, specifying this helps speed up parsing. I'll get to why in a bit. And for the Sources attribute on the task you should specify all the sources in the assembly, which @(Compile) works great for.

With the task added, you should be able to build and have a SiteMap.generated.cs file, now you'll need to tweak your "base" Controller class. If you're like us, you have a Controller class that you made yourself that all of your Controller's inherit from. In that class you'll need to add some code like the following:

private ICodeGeneratorServices _services;

public ICodeGeneratorServices CodeGeneratorServices
{
  get { return _services; }
}

public RootAreaNode Site
{
  get { return new RootAreaNode(this.ControllerServices); }
}

protected virtual void PerformGeneratedInitialize()
{
  _services = new DefaultCodeGeneratorServices(
    new DefaultControllerReferenceFactory(),
    new AspDotNetRedirectService()
  );
  _services.Controller = this;
}

First is the member variable, _services. You can do this however you like, but it's consumed by the ControllerAction/ViewReference classes to do various likes. CodeGeneratorServices is a property the partial controller code uses to create the MyActions and MyViews node instances. Site is just an easy way to get the top, root level node. PerformGeneratorInitialize is overridden in the partial controller classes to add the MyViews and MyActions nodes to the PropertyBag so they are available in the views. So there you go. If I'm not missing anything, that should do the trick. Let me know if I did and I'll append to this post.

Oh, the reason for specifying the ControllerSources is to cut down on the number of classes/types we visit when generating the internal "tree" that the source code is generated from. At first glance it seems like you should just be able to parse the ControllerSources only. We coudln't really do that because we needed to gather information on the other types in the assembly so we'd be able to use them in the arguments of our actions, etc... 

I have to stress that the code is relatively new, having undergone a major refactor to isolate it from the rest of our project. I make no promises that I won't have to upload a new copy, with a fix. :)

Source and Binaries

The Billings Gazette just published our first front page article!

Hello everyone. I just wanted to let those who responded to the string literal posts know what was "going on". Basically, we're still trying to find a way that we can release the source to some of our tools. I apologize for dragging my feet. I manage to keep pretty busy. Heh.

I was catching up on the castle-project's mailing list and found this post by Lee Henson. He's tossed together an implementation of a PropertyBag wrapper generator and posted the source. It's very similar to our approach. One main difference is that we do our generation at runtime so we don't have to generate and reference another assembly. We have an IViewFactory interface and a PropertyBagViewFactory implementation that hands them out. In tests we have an IViewFactory that pulls the views out of the MockRepository.

Incidentally, our code that does this lies with some other code for generating Control.Invoke proxies for our System.Windows.Forms view interfaces. It seems we're not the only people who do that particular type of generation. Rüdiger Klaehn has an article here about it. I strongly suggest reading it if you do any kind of SWF work.

In the thread I found a link to Brian Romanko's post about his implementation of the controller action/view SiteMap, as well as the PropertyBag wrapper. So just in case anybody gets impatient they can find something to tinker with over there. While his implementation is different from ours, the end result is very similar. I like his idea of generating a property for actions to refer to them without parameters.

I mentioned that for the SiteMap code generation we used CodeDom. CodeDom is great and means we don't have to use StringBuilder to construct C#. It also abstracts the language away. For those who are interested in this kind of code inspection/generation, I strongly suggest taking a look at N Refactory, it's a great library for parsing C#/VB.NET source. It's what we use and I've been incredibly happy with it. The only real hurdle when doing that kind or work is type resolution. I'll try and make a post about that in the near future.

Hosted on Zooomr

1 3007WFP + 2 2007FP = 4960x1600

Need I say more?