Robust Software

Questioning commonly held opinions

2010-02-04T12:37:00.001Z

I’ve been looking into rails recently, partly to learn rails itself, partly to try and gain inspiration for the direction to take both the framework we use at work and Jamaica. It’s triggered me to question a lot of things that I’m doing in .NET so I’m going to attempt to record my thoughts.

Having testing and persistence baked in

One thing that has struck me is that I’m watching railscasts from years ago and they are demonstrating solutions to problems ASP.NET MVC is struggling with now. It really does have testing baked in but often not through the use of abstractions, instead they have made integration tests easy to write. It appears the entire request can be processed in memory without having to fire up a server all the way through to rendering the view. This is something OpenRasta is capable of and one of the reasons I get so excited about it.

Another benefit rails has is that it comes with a “model” baked in. This is something that is sorely lacking from ASP.NET MVC. Whereas the .NET world (particularly the ALT.NET sphere) favours NHibernate for persistence, they instead use a simple but well implemented active record implementation. Why have they chosen this? Partially because it works so well with a dynamic language, everything is DRY as code can be generated from the database at runtime. It’s also damn quick, something that has always bugged me about NHibernate is the 10-20 seconds it takes to create the session factory before you can get started.

Because NHibernate is so powerful and configurable it can quite frankly be bloody confusing for most developers, I get asked to help with problems almost daily. With active record everything is kept simple, this object is a row in that table. There aren’t often complex mapping files, it just works. Rails’ active record implementation has a layer of syntactic sugar based around pattern matching on missing methods which looks nice and works well. However, in .NET we have LINQ which is statically typed, very powerful and can serve the same purpose.

Why do we chose NHibernate?

The reasons given for choosing NHibernate are persistence ignorance, reducing the impedance mismatch, amongst others. Why do we insist on ignoring the fact that our applications are running on top of a relational database? What ever happened to embracing the technologies we are using to get the best out of them?

NHibernate lets you persist your domain models directly. So what? Who’s domain models are that much beyond dumb data stores in reality? I’d bargain it’s a hell of a lot less than those that claim to be doing domain driven design. Also, why does your domain have to be persisted directly? Why couldn’t you provide an empty domain object with a few active record objects and have it process them and spit other active record objects out the other side? Something CQRS-ish. Then your domain would contain nothing but business logic.

What does this mean?

I’m looking away from NHibernate, no tool should be chosen without question, even the great NHibernate. I just don’t think it is serving my needs as well as it could so I’m going to look for alternatives. Subsonic is top of my list, followed by revisiting LINQ to SQL, hell I might even take a look at the Entity Framework.

While we’re at it, why do we chose relational databases without question? I’ve been working with Lucene.NET a lot recently, it’s really easy to use and you get full-text indexing for free if you were to use it as a data store. Only want to deal with aggregate roots? Store all the data of that aggregate root in a single document, it can easily emulate nested structures.

Random deviation onto REST

I’m also being influenced by how REST appeals to me. It seems like a simple yet powerful way of dealing with the web. If we consider everything we work with as a resource, a representation of an idea, why can’t that representation be stored as an active record? The transition of an idea between resources could actually be a record transferring between tables. The old representation could even hold a reference to what the idea became, allowing you to redirect to the current representation. Hell, wasn’t the web made for storing and linking documents before it got bastardised into the beautiful beast we have today? Perhaps a document database would be ideally suited!

Pain points of ASP.NET MVC

Talking of REST brings me back to another problem I have with ASP.NET MVC. The routing revolves around controllers and actions rather than the resources and HTTP methods. In order to generate URIs, you will at some point end up having to manipulate strings or create anonymous objects. How do rails and OpenRasta deal with this? By using resources and their types to determine the URIs. This is so much more powerful and dare I say easier to use and understand. I can see it empowering the use of generics within .NET and it cuts out a hell of a lot of crap around URI generation.

Ah, cutting out the crap. ASP.NET MVC is testable, until you want to test something that isn’t a just a controller action. Like a HTML helper, URI generation or store the IP address of the request. Most of these things are kind of testable, but you have to mock out a complex object graph like HttpContextBase or ControllerContext. “We got rid of HttpContext.Current and replaced it with something slightly less monolithic and slight less sealed, go us!”. Know how OpenRasta deals with this? It has dependency injection at it’s core and there’s an interface that lets you retrieve everything you need, either separately or together. There’s everything from IRequest to ICommunicationContext (the equivalent of ControllerContext) and everything in between. You need it, you can retrieve it and it’s bloody easy to test.

Wrapping up

There’s a lot of random ideas here, I can’t say which I’ll end up using. Perhaps none of them, perhaps an unforeseen combination. If nothing else writing this down has helped me distil a few of them into clearer thoughts.

Here’s to questioning everything you believe to be true.

Test-Driven Development – 3 Years On

2010-01-25T15:35:00.001Z

I’ve been questioning my own practices recently, seeing if there were places that I could improve, both in quality and productivity. Part of this process involved an evaluation of my test-driven approach (TDD) to developing software.

I have gained and learnt so much by practicing TDD. I believe there is no better way to instil the SOLID principle within both yourself and your code than to practice TDD. Violate any of the principles and you feel the pain in your tests, they will either become monolithic and hard to write or continuously break.

Here lies the chicken and the egg situation: to write good, robust tests you have to understand SOLID; to understand SOLID you have to be testing your code. This creates quite a hurdle that many people don’t put forth the effort to overcome. This is a shame but I think an excellent way of splitting the wheat from the chaff. In order to become proficient at testing you either need to have a natural talent for writing good code or the persistence to break through to the required level of understanding. Both of these qualities are equally valuable, having both would be fantastic.

The quality of code produced by TDD has never been in doubt in my mind. What I am questioning is the return-on-investment (ROI) of each test I write. Sometimes I feel I am writing a test for the sake of writing a test, producing very little value in the process. The kind of scenario where this is most apparent is the sort of code where if you were to not have written it properly nothing would happen or it would blow up in your face. Code with real binary levels of success, often with a single path through it.

This is the elephant in the room of all TDD discussions. When am I testing too much? The standard response of “NEVER!” is a lie but you have to have practiced TDD for a decent while until you can judge when you’re going to be writing tests with little worth. I’ve identified a subset of tests that I’m probably wasting my time in writing which are clouding the overall message of my test suite. The problem is that I am responsible for mentoring several developers in how and when to craft tests. I have to lead by example and until the whole team reaches a higher level of understanding of TDD I have to test everything despite knowing some of the tests I write have little to no value.

How can I test everything without writing these low value tests? Currently I’m looking at integration acceptance tests that describe the behaviour of the system. These will verify that the several layers of the application interact as expected in given scenarios to produce the desired behaviour of the system. These will likely have meaty setups and meaty verifications but they will remove the need for multiple low ROI tests. They are likely to be more brittle than unit tests but so long as I verify outcomes rather than interactions they should be fairly robust. What I’d love to experiment with is getting the stakeholders to help me write these acceptance tests, but this will have to wait until I’ve settled on a style for writing them. There’s nothing that harms adoption of a practice more than the first interaction to be a bumbling mess as you are not sure of what you’re doing!

As a company, we are also looking to hire testers this year. This is another thing stopping me from cutting out the low ROI tests. If I do not test my code, it will not get tested through anything but a manual process. Once we have testers I may be able to just write the tests that drive the behaviour and design of my code, leaving the full suite of tests to be developed by the testers.

So what have I learnt over the past few years? Is test-driven development worth the effort? Most definitely. The quality of my code has come on leaps and bounds and each time you do a major refactor of a well tested code base is a revelation. I find I write less code to do more and writing less code is always a good thing.

It’s harder to be sure you spend less time fixing bugs if I’m honest but I’m confident it’s the case. If you’re just starting out with TDD or unit testing in any form, start tracking the hours spent developing versus bug fixing. It would be interesting to see some empirical values on the subject.

Here’s to future years of TDD. It’s going to be interesting to see where my practices go.

A better ActionResult: Open Rasta edition (part 2)

2009-12-15T19:34:00.001Z

Sebastien Lambla, who created Open Rasta, mentioned that I could use an operation interceptor rather than using a pipeline contributor as in the first “A better ActionResult” post.

I must admit that I didn’t know about operation interceptors which is the main reason I didn’t use one in the first post. I took this as an opportunity to learn a bit more about Open Rasta and so looked into what operation interceptors are and how to create them.

Creating an operation interceptor is an unsurprisingly simple task. You can either implement the interface IOperationInterceptor or inherit from OperationInterceptor which implements IOperationInterceptor with virtual methods that have no effect on the operation.

The latter is the easiest thing to do so that’s what how we’re going to implement our interceptor.

The IOperationInterceptor has 3 methods: BeforeExecute, RewriteOperation and AfterExecute. We want to work with the result of the operation so we’ll override AfterExecute. The way the interceptor works once invoked is virtually identical to the pipeline contributor, bar a little refactoring, as you can see:

public class CommandOperationResultInterceptor : OperationInterceptor
{
    readonly IDependencyResolver resolver;
 
    public CommandOperationResultInterceptor(IDependencyResolver resolver)
    {
        this.resolver = resolver;
    }
 
    public override bool AfterExecute(IOperation operation, 
                                      IEnumerable<OutputMember> outputMembers)
    {
        var outputMember = outputMembers.FirstOrDefault();
        if (outputMember == null) return true;
 
        var command = outputMember.Value as CommandOperationResult;
        if (command == null) return true;
 
        outputMember.Value = ProcessCommand(command);
 
        return true;
    }
 
    object ProcessCommand(CommandOperationResult command)
    {
        resolver.AddDependencyInstance(command.GetType(),
                        command, DependencyLifetime.PerRequest);
 
        var commandHandlerType = typeof(CommandOperationResultHandler<>)
            .MakeGenericType(command.GetType());
 
        var commandHandler = (ICommandOperationResultHandler)
            resolver.Resolve(commandHandlerType);
 
        return commandHandler.Execute();
    }
}

This is a direct replacement for the pipeline contributor. It uses the exact same commands and command handlers as the pipeline contributor so the only other difference is that we have to register the operation interceptor rather than the pipeline contributor:

ResourceSpace.Uses.CustomDependency<IOperationInterceptor, 
    CommandOperationResultInterceptor>(DependencyLifetime.Transient);

That’s all there is to it. Really simple given we had the code for the pipeline contributor already.

The only difference between the pipeline contributor and the operation interceptor is that rather than dealing with a single operation result there could be multiple output members. From what I can gather there is only ever one output member which is the assumption I’ve embedded in the interceptor but I may be mistaken.

Reflecting on the two approaches, I don’t think there’s much to chose between the two. I prefer the original method of using a pipeline contributor. It is more visible via the debug output of the pipeline and it is easier to retrieve the operation result at that point. However, knowing that operation interceptors exist and how to use them is beneficial. Another weapon in my Open Rasta armoury.

A better ActionResult: Open Rasta edition

2009-12-14T19:39:00.001Z

I’ve been meaning to blog more about my experiences with Open Rasta but haven’t had a sufficiently focused topic to work with so far. However, whilst reading Jimmy Bogard’s post on a better ActionResult I thought doing similar would be equally possible with Open Rasta. Go off and read Jimmy’s post if you haven’t already because I’m going to assume you have.

First, some things to know about Open Rasta. It handles requests by passing them through a pipeline. Now this isn’t some mythical process that you have to spend hours working out as with MVC. It is instead made up of pipeline contributors which you register as part of your configuration. To help you debug Open Rasta prints out all the contributors in the order they’ll be executed for you during initialisation. Another difference in Open Rasta is what things are called, controllers are handlers, actions are operations, action results are operation results and models are resources. Their function is similar enough to require no further explanation in the context of this post.

Open Rasta gives you about 15 contributors to form the basis of request handling which you can replace or add to as you see fit. What we will do in order to emulate Jimmy’s code is create a new contributor and insert it into the pipeline. These are pretty simple to create and register, here’s all the code for our custom pipeline contributor:

public class CommandOperationResultInvokerContributor : IPipelineContributor
{
    readonly IDependencyResolver resolver;
 
    public CommandOperationResultInvokerContributor(IDependencyResolver resolver)
    {
        this.resolver = resolver;
    }
 
    public void Initialize(IPipeline pipelineRunner)
    {
        pipelineRunner.Notify(ExecuteCommand)
            .After<KnownStages.IOperationExecution>()
            .And.Before<KnownStages.IOperationResultInvocation>();
    }
 
    PipelineContinuation ExecuteCommand(ICommunicationContext context)
    {
        if (!(context.OperationResult is CommandOperationResult))
        {
            return PipelineContinuation.Continue;
        }
 
        var commandOperationResultType = context.OperationResult.GetType();
 
        resolver.AddDependencyInstance(commandOperationResultType, 
            context.OperationResult, DependencyLifetime.PerRequest);
 
        var commandHandlerType = typeof(CommandOperationResultHandler<>)
            .MakeGenericType(commandOperationResultType);
 
        var commandHandler = (ICommandOperationResultHandler) 
            resolver.Resolve(commandHandlerType);
 
        context.OperationResult = commandHandler.Execute();
 
        return PipelineContinuation.Continue;
    }
}

The Initialize method is called during initialisation so that Open Rasta can determine where in the pipeline you want your contributor to be invoked. The KnownStages class contains a bunch of interface aliases for significant stages in the standard pipeline allowing you to latch onto them without tying you to an implementation.

KnownStages.IOperationExecution is the Open Rasta equivalent of invoking the controller action and KnownStages.IOperationResultInvocation is the the equivalent of executing the ActionResult produced by the action. We’re slipping in between these two steps so we can execute our command handlers when needed; allowing us to change the OperationResult before it is executed.

So what do we actually do when this pipeline contributor gets invoked?

First we check if the OperationResult attached to the ICommunicationContext is of the CommandOperationResult type. This is identical to checking whether the ActionResult is of the BetterActionResult type in Jimmy’s post. If it isn’t we exit our pipeline contributor, telling Open Rasta to carry on to the next stage in the pipeline.

public abstract class CommandOperationResult : OperationResult
{
}

If it is a CommandOperationResult we retrieve the type of the current OperationResult and use it to register the OperationResult with our dependency resolver for the lifetime of the current request. The reason we do this is to be able to take the OperationResult as a dependency of the command handler. I’m not sure if this is any better but it does avoid using reflection to execute the command handler.

As a side note, Open Rasta uses an IDependencyResolver interface which is used throughout the codebase. It ships with it’s own implementation; I know there’s an implementation for Ninject and I think there’s one for StructureMap knocking around somewhere. I’ve only used the internal implementation as it does everything I’ve needed so far.

We then work out the type of CommandOperationResultHandler we’ll need to handle this command and use it to retrieve an instance from the dependency resolver. Again, this is very similar to Jimmy’s code apart from the fact that we cast the result as an ICommandOperationResultHandler. This is the second of the things that lets us avoid reflection.

public interface ICommandOperationResultHandler
{
    OperationResult Execute();
}
 
public abstract class CommandOperationResultHandler<T> 
    : ICommandOperationResultHandler
{
    protected readonly T command;
 
    protected CommandOperationResultHandler(T command)
    {
        this.command = command;
    }
 
    public abstract OperationResult Execute();
}

We execute the command handler, which will have taken the CommandOperationResult as a dependency due to us registering it earlier. It could also take the ICommunicationContext as a dependency as Open Rasta registers that for you, as it does for IRequest, IResponse and the other things that make up ICommunicationContext.

The result of executing the command handler is set as the OperationResult of the current ICommunicationContext, this encourages you to swap out the CommandOperationResult for one of the standard OperationResult objects which will then get handled as normal by the next stage in the pipeline, KnownStages.IOperationResultInvocation.

Here’s my equivalent of Jimmy’s DeleteRequestResult and DeleteRequestResultInvoker:

public class DeleteCommand<T> : CommandOperationResult
{
    public DeleteCommand(T resource)
    {
        Resource = resource;
    }
 
    public T Resource { get; private set; }
}
 
public class DeleteCommandHandler<T> 
    : CommandOperationResultHandler<DeleteCommand<T>>
{
    readonly ISession session;
    readonly ILogger logger;
 
    public DeleteCommandHandler(
        DeleteCommand<T> command, ISession session, ILogger logger) 
        : base(command)
    {
        this.session = session;
        this.logger = logger;
    }
 
    public override OperationResult Execute()
    {
        session.Delete(command.Resource);
        logger.WriteInfo("Deleted " + command.Resource);
 
        return new OperationResult.SeeOther
                   {
                       RedirectLocation = command.RedirectLocation
                   };
    }
}

This is how you would issue the delete command from your handler:

public class ResourceHandler
{
    readonly ISession session;
 
    public ResourceHandler(ISession session)
    {
        this.session = session;
    }
 
    public OperationResult Delete(int id)
    {
        var resource = session.Get<Resource>(id);
 
        return new DeleteCommand<Resource>(resource)
                   {
                       RedirectLocation = typeof(HomeResource).CreateUri()
                   };
    }
}

Last thing we need to do is register our pipeline contributor and command handler so they will be used.

ResourceSpace.Uses.PipelineContributor<CommandOperationResultInvokerContributor>();
ResourceSpace.Uses.CustomDependency<
    CommandOperationResultHandler<DeleteCommand<Resource>>, 
    DeleteCommandHandler<Resource>>(DependencyLifetime.Transient);

That’s all there is to it.

Personally I prefer how this works in Open Rasta but then I would say that. I like how the result is manipulated by adding a step to the pipeline rather than having to override behaviour as in MVC. It just seems tidier and more flexible. The other differences in implementation could be transferred and are probably a matter of personal preference.

Which do you think is better?

CQRS: Crack for architecture addicts

2009-12-10T08:51:00.001Z

I’m getting a bad feeling about yet another high-brow architecture. CQRS is a complex solution to a complex problem.

*NEWSFLASH*

Your problem is not complex enough to warrant the overhead of a complex solution

For the 1% of people who can rightly say “but my problem is complex enough” ask yourselves this: is it really that complex? I mean really.

Be honest now. Are you jumping at the latest architecture all the cool kids are talking about? Do you have twenty message buses passing data around because your intranet application might need to scale to millions of users one day? If you do, you probably don’t need CQRS for technical reasons but because you’re an architecture addict.

If you’ve got this far you either really do need to use CQRS or you have serious problem. So ask yourself this, you’re probably an architect or senior developer. Can the rest of your team fully understand the directions you’ll be giving from your ivory tower? If half of them can’t you are choosing the wrong architecture. I don’t care if it fits your problem perfectly. If your team can’t handle it, it’s the wrong choice.

If you still think CQRS is the right solution then you are in a very select group. You have a complex domain, scaling is a big problem for you and you have a team capable of taking the burden of a complex solution. Are you hiring?

That or you’re completely deluded.

Or you are a SOA consultant that is selling CQRS as the silver bullet for all development problems.

And I hate you.

What is BDD (Behaviour Driven Design)?

2009-11-09T20:36:00.001Z

“What is BDD?” is a question that’s been doing the rounds lately within the altnetgroup and devbookclub. There’s a great deal of mysticism surrounding it as if it were some exclusive members club. I’m going to slay some of the myths and tell you what BDD really is.

Myth 1: BDD requires a framework or tool

You don’t need to use MSpec, RSpec, Cucumber, etc to practice BDD. Sure they can help but they are not a precursor to being a practitioner of BDD. You don’t even have to write your tests within a certain construct such as Given-When-Then.

Myth 2: BDD requires UAT

User Acceptance Testing is a great concept but is one of those practices that only the elite working with an exceptional client get to do in real life. If you have UAT as part of your process, all power to you, but that’s all it is, part of your process. It is not part of BDD. It is merely coincidental that BDD style tests are the best way to express your acceptance tests.

Myth 3: BDD has to be done top-down

It is easier to approach BDD in a top down manner. But much like its easier to put your underwear on first, that doesn’t work for everyone in every situation. Just ask Superman. The proponents of BDD often state things in a radical fashion due to a fear of BDD being thrown in the same pot as TDD. That doesn’t mean that every time they say “you must” they actually mean it.

So what is BDD?

At its core, BDD is TDD done with a specific mindset; testing the intent of the system rather than testing a particular piece of code. The difference is subtle but the effects are large. There’s an entire discipline dedicated to the power of semantics after all.

It is the difference between “when I add a new post to my blog, the new post shows up on my homepage” and “calling the create new post method on the blog controller saves a new post and the new post is passed to the homepage view when the home controller’s index action is called”. Both sentences describe the same code, the BDD style signals the intent and is decoupled from the implementation. The non-BDD style describes what the code is doing almost line for line. The decoupling of the tests from the implementation is where the largest benefit of BDD comes from. Your tests will be less brittle making refactoring easier, perhaps even fun, making your code more malleable.

The myths aren’t completely unfounded, using constructs such as Given-When-Then helps enforce the required mindset. Frameworks such as MSpec, RSpec, Cucumber or even a bespoke one help you write tests within that construct. Working from the top-down helps you work from the behaviour of the user interface down to the behaviour of the data access. UAT helps you drive the behaviour of the system from the requirements of the client.

That’s all these things do though, help you develop in the BDD style. You can still write your code in a non-BDD style using all these frameworks, tools and processes, just as you can develop in the BDD style using none of them.

BDD is a state of mind.

BDD from scratch – Build your own framework (Part 2)

2009-09-13T17:51:00.001+01:00

In part one I covered how to organise your tests into the Given-When-Then style through the use of an abstract base class. In this post I’m going to show how you can manage your mocks more efficiently. Though not really a part of BDD I’ve found it very useful in clarifying the behaviour described in my tests as it reduces the amount of noise caused by the definition of variables.

I’m going to walk you through an example test, starting off with what we finished off with in part 1. We are going to be testing this standard ASP.NET MVC controller method:

namespace RobustSoftware.BddFromScratch.WebApplication.Controllers
{
    public class BooksController : Controller
    {
        private readonly IBookService bookService;
        private readonly IAuthenticationService authenticationService;
 
        public BooksController(IBookService bookService, IAuthenticationService authenticationService)
        {
            this.bookService = bookService;
            this.authenticationService = authenticationService;
        }
 
        public ViewResult YourBooks()
        {
            var currentUser = authenticationService.CurrentUser();
            ViewData.Model = bookService.OwnedBy(currentUser);
            return View("YourBooks");
        }
    }
}

I’m going to be using Moq as my mocking framework for this test; again I’ve applied the same concept to other frameworks such as Rhino Mocks. Here is how our test starts out:

namespace RobustSoftware.BddFromScratch.WebApplication.Test.Controllers.Books
{
    public class DisplayingYourBooks : BehaviourTest
    {
        private MockFactory factory;
        private BooksController controller;
        private Mock<IBookService> bookService;
        private Mock<IAuthenticationService> authenticationService;
        private ViewResult result;
        private List<Book> yourBooks;
        private User currentUser;
 
        protected override void Given()
        {
            factory = new MockFactory(MockBehavior.Loose);
 
            bookService = factory.Create<IBookService>();
            authenticationService = factory.Create<IAuthenticationService>();
 
            yourBooks = new List<Book>();
            currentUser = new User();
 
            authenticationService.Setup(x => x.CurrentUser()).Returns(currentUser);
            bookService.Setup(x => x.OwnedBy(currentUser)).Returns(yourBooks);
 
            controller = new BooksController(bookService.Object, authenticationService.Object);
        }
 
        protected override void When()
        {
            result = controller.YourBooks();
        }
 
        [Then]
        public void ShownYourBooksView()
        {
            Assert.AreEqual("YourBooks", result.ViewName);
        }
 
        [Then]
        public void PassedListOfYourBooks()
        {
            Assert.AreSame(yourBooks, result.ViewData.Model);
        }
    }
}

The obvious step to reduce the amount of test code on display would be to move the setup of the MockFactory up into the base class. We’re going to take it a step further than that though and introduce a mock management class. Here is what it looks like:

namespace RobustSoftware.BddFromScratch.Framework
{
    public class MockManager
    {
        private readonly MockFactory factory;
        private readonly IDictionary<Type, object> mockDictionary;
 
        public MockManager()
        {
            factory = new MockFactory(MockBehavior.Loose);
            mockDictionary = new Dictionary<Type, object>();
        }
 
        public Mock<T> Mock<T>() where T : class
        {
            var type = typeof(T);
 
            if (!mockDictionary.ContainsKey(type))
            {
                mockDictionary.Add(type, factory.Create<T>());
            }
 
            return mockDictionary[type] as Mock<T>;
        }
    }
}

This is a wrapper around a dictionary of mock objects. When we ask for a mock that has not been requested before, one is created. Otherwise, the previously created mock is retrieved from the dictionary and returned. We’ll add the creation of the mock manager to our abstract base class and expose the Mock<T> method for use within our tests:

namespace RobustSoftware.BddFromScratch.Framework
{
    [TestFixture]
    public abstract class BehaviourTest
    {
        private MockManager mockManager;
 
        protected Mock<T> Mock<T>() where T : class
        {
            return mockManager.Mock<T>();
        }
 
        [TestFixtureSetUp]
        public void Setup()
        {
            mockManager = new MockManager();
 
            Given();
            When();
        }
 
        protected abstract void Given();
        protected abstract void When();
    }
}

Now we can utilise the mock manager within our original test, reducing the lines of code considerably:

namespace RobustSoftware.BddFromScratch.WebApplication.Test.Controllers.Books
{
    public class DisplayingYourBooks : BehaviourTest
    {
        private BooksController controller;
        private ViewResult result;
        private List<Book> yourBooks;
        private User currentUser;
 
        protected override void Given()
        {
            yourBooks = new List<Book>();
            currentUser = new User();
 
            Mock<IAuthenticationService>().Setup(x => x.CurrentUser()).Returns(currentUser);
            Mock<IBookService>().Setup(x => x.OwnedBy(currentUser)).Returns(yourBooks);
 
            controller = new BooksController(Mock<IBookService>().Object, Mock<IAuthenticationService>().Object);
        }
 
        protected override void When()
        {
            result = controller.YourBooks();
        }
 
        [Then]
        public void ShownYourBooksView()
        {
            Assert.AreEqual("YourBooks", result.ViewName);
        }
 
        [Then]
        public void PassedListOfYourBooks()
        {
            Assert.AreSame(yourBooks, result.ViewData.Model);
        }
    }
}

As we no longer have to worry about variable declaration and assignment for our mocks, we can leave the test code to signal the intent of our test. As there is no real setup for the fields currentUser and yourBooks, I’d be tempted to in-line those variables but this is a matter of personal taste:

namespace RobustSoftware.BddFromScratch.WebApplication.Test.Controllers.Books
{
    public class DisplayingYourBooks : BehaviourTest
    {
        private BooksController controller;
        private ViewResult result;
        private List<Book> yourBooks = new List<Book>();
        private User currentUser = new User();
 
        protected override void Given()
        {
            Mock<IAuthenticationService>().Setup(x => x.CurrentUser()).Returns(currentUser);
            Mock<IBookService>().Setup(x => x.OwnedBy(currentUser)).Returns(yourBooks);
 
            controller = new BooksController(Mock<IBookService>().Object, Mock<IAuthenticationService>().Object);
        }
 
        protected override void When()
        {
            result = controller.YourBooks();
        }
 
        [Then]
        public void ShownYourBooksView()
        {
            Assert.AreEqual("YourBooks", result.ViewName);
        }
 
        [Then]
        public void PassedListOfYourBooks()
        {
            Assert.AreSame(yourBooks, result.ViewData.Model);
        }
    }
}

As you can see, this reduces the amount of code required to establish the same context to test a given behaviour. The less lines of code you need to set up a test, the easier it is going to be to understand that test in the future. This, along with the more explanatory naming of your test, makes it much easier to maintain that test in the future.

Next up, I’ll show how we can utilise our MockManager to implement auto mocking. This will reduce the amount of code in our test slightly, but more importantly it makes our test suite less brittle.

Related posts

BDD from scratch – Build your own framework (Part 1)

2009-09-06T16:00:00.000+01:00

BDD is a higher level of unit testing, it creates better documentation of your system by recording its intent which makes your system easier to learn for new developers and relearn for when you revisit your code further down the line.

I’m going to show you how to build your own BDD testing framework on top of a vanilla unit testing framework. For my example I’m going to use NUnit but I’ve applied the same principles with MbUnit, xUnit and it should work with any other unit testing framework too.

What’s good about doing things this way, as opposed to using a purpose built BDD framework like MSpec, is that it allows your tests to exist and be run side-by-side with traditional unit tests. This can ease the migration to the new style if you’re all moving over to it and it lets you write tests in the BDD style for some parts of the system whilst sticking with the traditional unit style for other parts. Though I’ll be amazed if you don’t end up writing all your tests in the BDD style as everyone I’ve shown it too loves it.

I’ll show you how to create the basis for your own BDD framework and I’ll give an example of how a BDD style test looks in comparison to a traditional unit test.

What is BDD all about?

The core concept of BDD is Given-When-Then (often referred to as Arrange-Act-Assert):

Given the system is in a certain state (the context of the test)
When an action is performed on the system (normally calling a single method)
Then a list of assertions should be satisfied

Herein lies another fundamental difference with BDD, you will create a test fixture per scenario rather than a fixture per class as it common with traditional unit testing.

The basis of our framework

The way to transform your standard unit testing framework to a BDD one is to use an abstract base class. This will modify how your tests are run, giving you the ability to specify your Given, When and corresponding Thens separately from one another:

using NUnit.Framework;
 
namespace RobustSoftware.BddFromScratch.Framework
{
    [TestFixture]
    public abstract class BehaviourTest
    {
        [TestFixtureSetUp]
        public void Setup()
        {
            Given();
            When();
        }
 
        protected abstract void Given();
        protected abstract void When();
    }
}

This means that the contents of your Given and When methods will be run once before each of your methods decorated with the Test attribute are run. This is important as it means that all your assertions should not have side effects (this should be the case already). You will use it in a test class by doing something like this:

using System;
using NUnit.Framework;
 
namespace RobustSoftware.BddFromScratch.Framework
{
    public class ExampleBehaviour : BehaviourTest
    {
        protected override void Given()
        {
            // the system is setup in a certain state
        }
 
        protected override void When()
        {
            // a defined action is performed on the system
        }
 
        [Test]
        public void ThisAssertionShouldBeSatisfied()
        {
            Assert.IsTrue(true);
        }
 
        [Test]
        public void AnotherAssertionShouldBeSatisfied()
        {
            Assert.IsTrue(true);
        }
    }
}

Notice that the intent verified by each assertion is documented in the name of the test method. This means that when you run your tests, the name of the tests themselves show you when was meant to happen rather than the error messages that most people forget to add to their assertions.

Another thing that I like to do but is entirely optional is alias the Test attribute to be able to use a Then attribute with the same behaviour:

using NUnit.Framework;
 
namespace RobustSoftware.BddFromScratch.Framework
{
    public class ThenAttribute : TestAttribute
    {
    }
}

This just changes the original example test slightly so it’s more obvious how the Given-When-Then style is being applied:

using System;
using NUnit.Framework;
 
namespace RobustSoftware.BddFromScratch.Framework
{
    public class ExampleBehaviour : BehaviourTest
    {
        protected override void Given()
        {
            // the system is setup in a certain state
        }
 
        protected override void When()
        {
            // a defined action is performed on the system
        }
 
        [Then]
        public void ThisAssertionShouldBeSatisfied()
        {
            Assert.IsTrue(true);
        }
 
        [Then]
        public void AnotherAssertionShouldBeSatisfied()
        {
            Assert.IsTrue(true);
        }
    }
}

Converting a traditional test

I’ll start of with what I think to be a pretty standard unit test that I found in the source of OpenRasta:

[Test]
public void a_change_after_a_creation_results_in_a_new_oject_with_the_same_properties()
{
    var binder = new KeyedValuesBinder("customer", typeof(Customer));
    binder.SetProperty("username", new[] { "johndoe" }, (str, type) => BindingResult.Success(str));
    binder.BuildObject();
 
    binder.SetProperty("firstname", new[] {"john"}, (str, type) => BindingResult.Success(str));
    var customer = (Customer)binder.BuildObject().Instance;
 
    customer.Username.ShouldBe("johndoe");
    customer.FirstName.ShouldBe("john");
}

As I see it this, like many other traditional unit tests, is already split into the Given-When-Then style logically:

[Test]
public void a_change_after_a_creation_results_in_a_new_oject_with_the_same_properties()
{
    // Given - the context we are establishing in the system
    var binder = new KeyedValuesBinder("customer", typeof(Customer));
    binder.SetProperty("username", new[] { "johndoe" }, (str, type) => BindingResult.Success(str));
    binder.BuildObject();
 
    binder.SetProperty("firstname", new[] {"john"}, (str, type) => BindingResult.Success(str));
 
    // When - the action we are performing on the system
    var customer = (Customer)binder.BuildObject().Instance;
 
    // Then - checking the system ends up in the desired state
    customer.Username.ShouldBe("johndoe");
    customer.FirstName.ShouldBe("john");
}

So splitting it physically into the separate sections is not much of a leap:

public class ChangingAnObjectAfterACreation : BehaviourTest
{
    private KeyedValuesBinder binder;
    private Customer customer;
 
    protected override void Given()
    {
        binder = new KeyedValuesBinder("customer", typeof(Customer));
        binder.SetProperty("username", new[] { "johndoe" }, (str, type) => BindingResult.Success(str));
        binder.BuildObject();
 
        binder.SetProperty("firstname", new[] { "john" }, (str, type) => BindingResult.Success(str));
    }
 
    protected override void When()
    {
        customer = (Customer) binder.BuildObject().Instance;
    }
 
    [Then]
    public void UsernameShouldBeJohnDoe()
    {
        Assert.AreEqual("johndoe", customer.Username);
    }
 
    [Then]
    public void FirstNameShouldBeJohn()
    {
        Assert.AreEqual("john", customer.FirstName);
    }
}

I've dropped the use of the assertion extension methods that Sebastien Lambla was using (I’ll cover how to write those later in the series), but otherwise the actual test code has remained the same.

The physical separation of the logical parts of the test makes the test easier to follow and the assertions at least as explicit even without the extension methods being used.

The fact that BDD makes the separation many people already make when writing traditional unit tests more explicit is why I and other people like it. It makes your tests more readable as you can often skim the Given section as that should be conveyed by the name of the entire fixture. That leaves you to see what method is being called and the assertions being made. These are often now more descriptive as they are given a method name.

If you’ve got any questions, leave a comment and I’ll reply as soon as I can. Do the same if you’ve any related topics you’d like to see covered. I’m planning on covering, mock management, auto-mocking, fluent test extensions and shared contexts.

Related posts

If your code isn't tested, it doesn't work

2009-08-19T13:53:00.001+01:00

I test-drive my code. That means, by definition, that each line is covered by at least one test. I know my code works today and tests ensure it still works tomorrow, next week and next year.

If your code isn't tested you may know it works today, after drawn-out manual testing through each scenario. But what about tomorrow? Are you going to do the manual tests for today's work? Come next week are you going to be performing manual tests for this week's work? Of course you're not, you'd never get anything done.

By testing your code you are eliminating the majority of emergent bugs as soon as they happen (you are doing continuous integration aren't you?). This means you produce features faster in the medium to long term as you minimise the number of bugs that arise. A win for business as costs are reduced as well as lead time. I don't know about you but I prefer adding features to chasing bugs too.

If you're not testing, you must enjoy debugging.

A better domain event raiser

2009-08-03T12:54:00.002+01:00

There was a lot of discussion about domain events at AltNetUK around Udi Dahan's recent article. Please read that first so that you’ll know the context of what I’m about to say, I’ll still be here. Might be useful to have them side-by-side.

I couldn’t help when reading it that the code around event dispatching was quite a mess, with code added in for multiple, distinct scenarios (live and test). This may just have been to help with the formatting of the article, but it leaves a lot to be desired.

What I’m going to do here is show my refactored version of the code and explain why I think it is better. What I’m going to be doing is utilising the strategy pattern to separate the logic of dispatching events from the action of requesting an event to be dispatched.

In figure 1 of the testability section Udi shows how the DomainEvents class ends up. Here is how mine looks after the refactoring:

public static class DomainEvent
{
    public static IEventDispatcher Dispatcher { get; set; }
 
    public static void Raise<TEvent>(TEvent eventToRaise) where TEvent : IEvent
    {
        Dispatcher.Dispatch(eventToRaise);
    }
}

This is made possible because I’ve abstracted the dispatching of the event into a separate class implementing the IEventDispatcher interface:

public interface IEventDispatcher
{
    void Dispatch<TEvent>(TEvent eventToDispatch) where TEvent : IEvent;
}

There would be two implementations of IEventDispatcher in normal projects. One to be used at runtime such as this one utilising StructureMap:

public class StructureMapEventDispatcher : IEventDispatcher
{
    public void Dispatch<TEvent>(TEvent eventToDispatch) where TEvent : IEvent
    {
        foreach (var handler in ObjectFactory.GetAllInstances<IEventHandler<TEvent>>())
        {
            handler.Handle(eventToDispatch);
        }
    }
}

And one to be used during unit tests such as this one:

public class ActionEventDispatcher : IEventDispatcher
{
    private readonly IDictionary<Type, Delegate> handlers;
 
    public ActionEventDispatcher()
    {
        handlers = new Dictionary<Type, Delegate>();
    }
 
    public void Register<TEvent>(Action<TEvent> eventAction) where TEvent : IEvent
    {
        // assuming you'll only register once per test
        handlers.Add(typeof(TEvent), eventAction);
    }
 
    public void Dispatch<TEvent>(TEvent eventToDispatch) where TEvent : IEvent
    {
        if (!handlers.ContainsKey(typeof (TEvent))) return;
 
        var handler = (Action<TEvent>) handlers[typeof (TEvent)];
 
        handler.Invoke(eventToDispatch);
    }
}

You’ll notice that the two event dispatchers are the two sides that can be executed in Udi’s implementation. That is the essence of the strategy pattern.

This does modify the test slightly so that you now have to do this:

[Test]
public void DoSomethingShouldMakeCustomerPreferred()
{
    var c = new Customer();
    Customer preferred = null;
 
    var eventDispatcher = new ActionEventDispatcher();
 
    DomainEvent.Dispatcher = eventDispatcher;
 
    eventDispatcher.Register<CustomerBecamePreferred>
        (p => preferred = p.Customer);
 
    c.DoSomething();
    Assert(preferred == c && c.IsPreferred);
}

I would put the attachment of the ActionEventDispatcher into a test base class so that you didn’t have to set it up for every test, reducing the noise added.

You would also have to add a small bit of code to hook up your real event dispatcher when your application started:

public void SetEventDispatcher()
{
    DomainEvent.Dispatcher = new StructureMapEventDispatcher();
}

Still not sure whether I like the use of domain events or not. However, I did notice this potential refactoring whilst reading the article and thought it was interesting enough to blog about. I think it has left the code in a much better state and I think it also addresses some of the concerns that were raised about the static class at AltNetUK.

POST overload – implementation considerations

2009-07-25T20:15:00.001+01:00

As I have been blogging about, I’ve been fighting with myself over the best way to implement POST overloading in RESTful ASP.NET MVC. I’m still not happy that I have chosen the best implementation in using the URL to indicate the overload but I’m done with thinking about it for now. I’m going to record my and others thoughts about the pros and cons of each approach and move on to other functionality.

The two main points around which the discussion revolves are transparency and adherence to the spirit of HTTP. A compromise has to be made on one of them, which you choose to compromise, I feel, is a personal decision.

Using a hidden form value for overloading is transparent to the user, the URL the POST is made to does not change. My previous argument for needing to implement overloading for different content types is nonsense as you would never need to use POST overloading apart from when POSTing a form from a browser. All other calls will be able to use the correct HTTP verb directly.

The URL overloading method, for me, remains closer to the spirit of HTTP. If the URL contains the overload you know how to handle the request purely from the head of the HTTP request. Using the form value method you need to check the body of the HTTP request to know what to do.

Neither method is ideal, they both have their compromises and I can’t honestly say whether one is better than the other at the moment. Perhaps I’ll obtain some insight later that makes one clearly better than the other. However, I do know that at the moment I’m risking the wrath of Scott Bellware:

@gshutler ultimately, i'm gonna come gunning for you if this hack-in-the-uri becomes convention in the late-to-the-game .net rest users :) Sat 25 Jul 01:20

If you find me in a ditch because everyone starts using the URL overload method, you have a prime suspect.

I’d like to thank Scott Bellware and Sebastien Lambla for taking the time to talk to me about this subject over the past couple of weeks on twitter, it’s greatly appreciated.

Overloading POST – a change of mind

2009-07-24T21:52:00.005+01:00

Today I made a fairly fundamental change in design of RESTful ASP.NET MVC revolving around how I will be overloading post for HTML forms.

Previously I was adding a hidden field to the form, which is how it is done by Rails:

<form method="POST" action="/Users/2">
<input value="DELETE" type="hidden" name="_method" />
<input value="Delete" type="submit" />
</form>

I was aware of OpenRasta's method of overloading post which is to append the overload to the URI:

<form method="POST" action="/Users/2!DELETE">
<input value="Delete" type="submit" />
</form>

However, I didn’t like the way the overload was opaque to the user and thinking that the Rails guys must have thought about it a fair bit I initially went with the former method.

I ended up having a discussion with Sebastien Lambla, the developer of OpenRasta, about the two options and why he had chosen the second method over the first (I love twitter for this). To be honest, I came away from the discussion thinking there wasn’t much to chose between the two, it just being down to a matter of preference. However, I kept thinking about it, questioning my decision and whether it my choice really was better than the other option.

I had a moment of clarity whilst playing golf. I realised that, potentially, I might have to write post overload mechanisms for multiple formats as clients could submit requests in a variety of formats (XML, JSON, form, etc). If the overload is contained within the URL then the overload is independent of the body’s content type, simplifying things considerably.

Now I had a reason to change, I did so, changing RESTful ASP.NET MVC’s method of overloading post to the URI mechanism. As it happens this tidied up the code a little as I no longer had to pass around the form collection, I could work purely off the routing values.

UPDATE

I have written a follow-up post about the implementation considerations for POST overload that I recommend reading as well.

ASP.NET MVC Route Testing with HTTP Verbs

2009-07-18T21:21:00.001+01:00

I’ve started RESTful ASP.NET MVC from scratch and I am test-driving it. Writing code without tests is ok for proofs of concept but as I was planning on continually adding to the project I felt I had to start again and make sure everything was tested. As part of the process I was looking to test my routing rules. I used Phil Haack’s route testing helper as a starting point but I think I’ve customised it enough to warrant a post.

The first thing I did was change his static method into an extension method. However, my routes were also dependant upon the HTTP verb used so I had to add that in on top. I also needed to check that a route wouldn’t be matched for the same reason as a URI which is valid for a GET may not be valid for a POST.

My route test helper and an example of it in action from the test-driven branch of restful-aspmvc.

Related posts

RESTful ASP.NET MVC

2009-07-17T13:11:00.001+01:00

This is the first in what could be a series of posts on how to modify the internals of ASP.NET MVC in order to make it work in a more RESTful manner. If you want to work with a RESTful web framework built on .NET today then I recommend using OpenRasta.

The reason I’m doing this is two-fold:

I want to learn more about REST beyond the theory and I learn more by doing.
Sometimes it’s impossible to convince people to use an open source framework like OpenRasta, but customising stuff produced by Microsoft is much better received. I hope this will help other people write more RESTful sites whilst using Microsoft-based frameworks.

All the code I will be referring to is available on the restful-aspmvc project page. At the time of writing this the code was on revision 3, so if you are reading this later on there my be some inconsistencies.

The inspiration

I wanted to be able to use RESTful URLs like those available in Ruby on Rails. These work by selecting the controller action through the use of the URL and the HTTP verb.

GET /users/               UsersController.Index()

POST /users/              UsersController.Create()

GET /users/{id}           UsersController.Show(id)

PUT /users/{id}           UsersController.Update(id)

DELETE /users/{id}        UsersController.Destroy(id)

I then wanted to allow you to create different views of the resources by specifying other actions that can only use the GET verb like so:

GET /users/{action}       UsersController.{Action}()

GET /users/{id}/{action}  UsersController.{Action}(id)

The implementation

The above routes are achieved through these route mappings: listing on Google code

The next problem was to map to the different actions according to the URL and the HTTP verb. As web browsers only support GET and POST this requires a technique known as overloading POST. I tried doing this in a couple of ways, firstly by including the required HTTP verb in the URL:

/users/{id}?verb=DELETE

However, I found this quite ugly. As we are overloading POST, there will always be a form involved, therefore I’ve specified the required verb (where necessary) with a hidden form field:

<form method="post" action="/Users/2">
    <input value="DELETE" type="hidden" name="_verb" />
    <p>        
        <input value="Delete" type="submit" />        
    </p>
</form>

Now the verb is specified in the form, we have our URLs working we now need to act on this information. For that I have used a customer controller factory (Google code listing).

There’s a fair bit of code to include directly into a blog post so I’ll explain the general flow to you and if you’re interested in the implementation you can have a look at the listing.

When the controller is created we use the default implementation to retrieve the controller and give it a custom action invoker to use.
When the action is invoked we first check if the verb being used is a POST, if it is we check the form for an override. If one exists we change what we think the HTTP verb is to the one passed.
If no specific action has been used (the default action is Index because of the routes we specified) then we use the HTTP verb and whether an id was specified to determine the actual action required.
We use the default implementation to invoke the action required.

The full code listing includes a basic site which shows all the overrides being used along with a couple of common custom views (new and edit are commonly used to display forms to create and update resources).

This is the first step towards making ASP.NET MVC more RESTful. I welcome your comments and feedback, especially if there is something in particular you’d like me to implement in the future.

REST – a quick summary

2009-07-12T19:28:00.001+01:00

I’d read a lot of blogs talking about REST and it’s benefits but I hadn’t fully got it. Whilst on holiday I read RESTful Web Services, which I had seen recommended, in an effort to try and finally grok REST.

I thoroughly recommend this book, it helped me connect a lot of previously separate ideas into a coherent whole. What I hope to do here is give an overview of what I’ve learnt from the book to act as a reference to myself and maybe help other people in the process.

Definition

REST is short for Representational State Transfer. Distilled down, it’s basically about using the HTTP verbs, GET, POST, PUT, DELETE and HEAD, in order to act on resources, represented by individual URIs.

Resources are similar to what most of you will think of as domain entities. However, a relationship between two entities can be represented by a resource.

Underlying principle

The main idea behind REST is that you are working with the HTTP protocol. Other web service ideas like SOAP, referred to in the book as Big Web Services, mostly ignore the expressiveness of the HTTP protocol and use only GET and/or POST requests. This often works against the HTTP protocol, at best it ignores .

The requests and responses of the HTTP protocol consist of a head and a body. The analogy used in the book is one of an envelope, the head being the envelope and the body being the contents of the envelope. REST uses the URI, HTTP verbs, HTTP headers and HTTP response codes in order to communicate to the server what is wanted and to the client what happened.

This is in contrast to SOAP which generally uses the URI from the head and then sends another envelope in the body to communicate more information about the request to the server and the response to the client. This is effectively putting an envelope inside another envelope.

HTTP verbs and their meanings

The beauty of the verbs are that they are mostly self-explanatory, but I’ll explain all of them for completeness.

GET

This verb means give me the current representation for the given URI. You can use headers to modify the behaviour slightly. For example, the If-Modified-Since header can be used to say “only send me the representation for the URI if it has changed since the given date”. This can be used to minimize needless traffic and processing.

DELETE

This verb means delete the representation at the given URI. There’s not really anything complicated about it.

HEAD

This is equivalent to a GET request but only returns the HEAD of the response, omitting the BODY. This is used for getting the meta data about a resource, for example checking whether a resource exists at a given URI without retrieving the BODY as well.

POST and PUT

I’ve put these two together as they are the ones I previously had most difficulty differentiating between. Needless to say the book explained the difference perfectly.

PUT is used to place a resource to a specific URI (eg. /Product/1), this can be a resource that didn’t exist before (an insert) or replace the existing representation at that URI (an update). In contrast, POST is used to add a resource to the end of a list of resources (eg. /Product) when you don’t know the URI in advance (an insert). Once you know the URI of your new resource, you will use a PUT to update it.

REST and HTML forms

A problem I had was reuse of web service code with web sites, HTML only supports the verbs GET and POST. I was concerned about having to maintain two sets of code for acting on the same resources. This can be overcome by using a concept called overloaded post.

The idea behind it is really simple, you include the verb you want to use as a query string parameter and POST to that URI (eg. /Product/1?method=DELETE). Then using some simple server-side code you handle the request as the verb passed instead of as a POST.

Conclusion

I’ve covered the main concepts that helped me understand the big picture of REST. I really think it is the best way to write web services so that they can be easily consumed by other people. The emphasis of REST is on simplicity, utilising the power of the HTTP protocol rather than building a new protocol on top of it. This goes against the common practice up until this point, which to me is a breath of fresh air.

Finally, I strongly recommend you buy the book if you are interested in learning more about REST.

Nott Tuesday and the altnetbeers format

2009-07-10T18:55:00.001+01:00

As I said previously I’ve volunteered to lead this month’s Nott Tuesday event, taking place this coming Tuesday, 14th July.

So, as promised, I’m going to give the outline of how the whole evening will work. Hopefully it will encourage more participation from the whole group in the discussion, improving the night for everyone.

Topic selection

So a little while after 18:30, once everyone has had the chance to say hellos and so forth, I’ll ask everyone to volunteer topics for discussion. I’ll provide a stack of index cards and pens and anyone who has something they’d like to talk about can write a question on a card and put it onto a table for others to see. Something as vague as “why agile?” or specific as “how do I leverage e-marketing to obtain new business?” is fine. Framing it as a question will probably work better, but if you can’t do that then a simple sentence will do. The idea is to give the group a starting point for a discussion.

Once we’ve had 5-10 minutes to write down our ideas we will whittle them down to the few most popular topics by voting on the ideas as a group. We’ll start off with the most popular topic and if the discussion is lively enough for long enough that might be all we discuss all night but if things start tailing off we’ll move on to the next most popular topic.

How does the discussion work?

There will be a “bench” where 3 people sit, they are the panel of which the group can ask questions. To begin with I’ll ask whichever person raised the topic to speak for 30 seconds or so just to explain a bit further what they want to get from the discussion. This person will also start off on the bench along with 2 volunteers. It is then thrown to the floor to ask questions of the bench. If you have a question, raise your hand and I’ll pick a person at a time to ask their question to stop it being a free-for-all. If you are part of the audience, you can only ask questions or come back on the answers given by the panel when applicable.

If it is a topic you are interested in and have something to say about it, you can go and sit in the “hot seat”, this signifies you want to be on the bench and answer questions. When someone is in the hot seat, someone from the bench is obliged to return to the audience, allowing the person in the hot seat to move onto the bench. This can manage itself by people not having more to say or wanting a break, but if not we’ll do it on a first-in-first-out basis.

A personal plea

Please be gentle with me, it’s the first time I’ve run something like this so bear with me a bit. I might need to cut you off if you’re in the middle of a heated discussion but the majority of the room looks bored, please bear in mind I’m trying to keep it interesting for the whole group. There’s nothing to stop your carrying on the discussion afterwards of course!

That’s all there is to it really. Hopefully, it will result in an enjoyable evening for everyone, having lively discussions about topics we’re all interested in.

See you at Bluu on Tuesday 14th July at 18:30!

Nott Tuesday – July 14th

2009-06-25T12:57:00.001+01:00

So I went to Nott Tuesday for the first time last month and really enjoyed it. Adam Bird, the guy who started it up seemed keen to move towards group discussion rather than one or two people presenting to the group.

I’d been to a similar event before, altnetbeers, which is run by Sebastien Lambla in London. Altnetbeers had the sort of group discussion I felt Adam was looking for so I dropped him an email the next day explaining the format to see what he though.

Well I should have known better because, as has now been announced, Adam said he liked the sound of it and asked me if I wanted to lead the next meeting in the style of altnetbeers. I couldn’t well say no after telling him how great it was so here we are.

I’ll be cross posting an explanation of how it all works a bit nearer the time so that people will have an idea of what will be happening on the night.

Opening a Command Prompt for the solution in Visual Studio

2009-06-17T12:54:00.001+01:00

Something I’ve found myself needing to do more recently is open a command prompt at the root directory of my solution. Often this is to run a rake task or something like that.

The way I used to do this was rather long winded, but now I’ve got it down to a single key combination and I’ll explain here how you can do the same.

Firstly, open up the external tools dialog in Visual Studio:

Then add a new tool:

This will give you a prompt to type the details of the new tool into:

Then fill in the details of the new tool. We want to point this at cmd.exe which is usually located in your System32 directory. You also want to set the initial directory to the solution directory:

I have then moved the tool up the list just because I like it being higher. The position of the tool in the list only makes a difference when setting up a keyboard shortcut as I will explain in a minute:

Once you’ve filled in all the details and moved the tool to the position you want it in just click Ok. You will now see that the tool you just created appears in the external tools section of the tools menu:

Now we can set up a keyboard shortcut for the new tool. Firstly, open the options dialog:

Then go to the keyboard section:

Then type in the command name “Tools.ExternalCommandX” where X is the number your tool appears in the list. Mine is second so I type “2”:

Then assign a key combination to this command. I chose Ctrl+Shift+Alt+C:

Then click ok and you will now be able to open a command prompt at the root of the current solution with your key combination.

This principle can be extended to call any program, you may have noticed I use it to call the default rake task for my solution.

Establishing Team Values

2009-05-15T14:05:00.001+01:00

One of the biggest things I took from the Progressive .NET tutorials was the idea of establishing a set of values for your team.

This was raised in David Laribee’s session Towards A New Architect (watch out for the video of that coming out) where he asked whose team had a set of common values. In a room of 30 or so people, I think 3 or 4 raised their hand.

As soon as it was mentioned it made sense to me. A shared identity and core set of values can only benefit a team. To that end I’m going to run a similar session to the one I participated in in order to establish a set of values for my team.

I thought I might share the format I’m going to use so that others might do the same:

Set up a 1 hour session for discovering your team’s values

5 minutes explaining what we are doing and what we want to achieve

bring common values to the fore
give a common identity to the team
create a catalyst for improvement

DIVERGE, CONVERGE, SYNTHESIZE

5 minutes writing words or short phrases down
5 minutes converging to write all the different phrases on the board by going round the group
2 minutes dot voting
1 minute selecting top 3-5 by votes

DIVERGE, CONVERGE, SYNTHESIZE

10 minutes to write a sentence explaining why each phrase is important (each person doesn't have to do each one)
10 minutes coming together, taking each word in turn and sharing sentences all written on the board
2 minutes tweaking and eliminating duplicates
2 minutes dot voting each group of sentences
select the favourite sentence for each phrase

Your team now has a set of common values

Thank the team and tell them you are going to get them printed to put up on the wall. The important thing is that they are visible and prominent.

Important points

the number of values should be low – the messages should be simple and strong
the values should be visible to the whole team, all the time
everyone should be empowered to act to strengthen the values

I’ll blog about what values my team at Open Projects have chosen next week.

Great replication troubleshooting article

2009-05-14T11:46:00.000+01:00

I found this article on troubleshooting replication woes, unfortunately it requires you to sign up for SQL Server Central. However, if you have the “pleasure” of dealing with replication it gives a lot of good pointers on sorting out problems so it’s worth it.

Related posts:

SQL Server 2005 replication errors table

When geek rockstars go wild

2009-05-14T09:35:00.001+01:00

Ok, a silly one but I’ve got to share this. When walking to the hotel on Sunday before Progressive .NET I saw this in the middle of the pavement:

I’m guessing someone broke the build and this is what happened to their monitor.

Progressive .NET Tutorials

2009-05-09T19:21:00.001+01:00

I will be attending the Progressive .NET Tutorials next week and I must say I’m looking forward to it. It’s slightly disappointing that Scott Bellware couldn’t make it for his testing track on Monday but there’s plenty of other things going on. This is my plan for the week:

Sunday

Travelling down from Nottingham with Andrew Bullock and checking into the Farringdon Travelodge down the road from Skills Matter. Nothing planned for this evening, probably get something to eat and then hit the hay before a busy few days.

Monday

Going to start the morning with Specification by example and Agile acceptance testing led by Gojko Adzic, it will be good to hear someone talk about testing as everything I’ve learnt has been picked up through screencasts and blogs.

For the afternoon I’m uncertain whether to go for Gojko’s FitNess.NET workshop or Sebastien Lambla’s workshop on OpenRasta. I think how well I get on with Gojko’s style of presentation in the morning will be the deciding factor.

In the evening I’m attempting to arrange a meal with other people from the tutorials then probably go to a bar for a drink or two.

Tuesday

I’m going to spend the whole day with Oren Eini learning about NHibernate. Again this is something I’m using already but all I’ve learnt is taken from the internet. Learning from one of the developers of NHibernate is an opportunity that cannot be missed.

In the evening Sebastien Lambla has arranged AltNetBeers where there will be an OpenConf style discussion. I’m looking forward to this nearly as much as the tutorials themselves.

Wednesday

Going to spend this day listening to David Laribee's thoughts on project management and teamwork. I’m hoping to come away from this with inspiration on how I can help improve my team’s practices.

Finishing it all off Skills Matter have arranged a trip to a pub for a drink or two. I’ll be spending about an hour there before catching the train back to Nottingham.

Thursday and Friday

I’m planning on blogging about the things I’ve learnt over the previous 3 days. So look forward to a raft of blog posts.

I might get chance to knock together a blog post, but I’ll be tweeting whenever I get half a second spare so follow me if you’re interested in what’s going on.

RhinoMocks IQueryable helper

2009-05-09T14:57:00.001+01:00

After reading Lee Brandt's post about how my answer to his question on Stack Overflow helped with testing the logic of his queries I realised that people might find one of my test helper extension methods useful.

I found that in my tests I had to mock out the Query<T> function quite a lot which would look something like this:

    1 protected override void EstablishContext()
    2 {
    3     var projects = new[]
    4                    {
    5                        Build.Project().WithName("AAAAAAA").Create(),
    6                        Build.Project().WithName("CCCCCCC").Create(),
    7                        Build.Project().WithName("BBBBBBB").Create()
    8                    };
    9 
   10     Mock<IUnitOfWork>()
   11         .Stub(x => x.Query<Project>())
   12         .Return(projects.AsQueryable());
   13 }

This was adding quite a lot of noise to my tests. I like to keep my tests as clean as possible to make them easier to scan when you need to review and understand them. Because of this I wanted to simplify the stubbing so there was as little code as possible.

This was made possible by this simple extension method:

    1 public static IMethodOptions<IQueryable<TEntity>> ReturnQueryable<TEntity>
    2     (this IMethodOptions<IQueryable<TEntity>> options, params TEntity[] items)
    3 {
    4     return options.Return(items.AsQueryable());
    5 }

The magic sauce in this is the items parameter. I’ve used the params modifier so that I can provide any number of TEntity objects for the IQueryable function to return.

This tidies the above setup code down to this:

    1 protected override void EstablishContext()
    2 {
    3     Mock<IUnitOfWork>()
    4         .Stub(x => x.Query<Project>())
    5         .ReturnQueryable(
    6             Build.Project().WithName("AAAAAAA").Create(), 
    7             Build.Project().WithName("CCCCCCC").Create(),
    8             Build.Project().WithName("BBBBBBB").Create()
    9             );
   10 }

I find this much cleaner and easier to read, hope this helps someone out.

Happy testing!

Related posts:

A new name for ALT.NET

2009-05-08T13:17:00.001+01:00

I will be attending Progressive .NET Tutorials next week and it got me thinking this morning.

Wouldn’t Progressive .NET be a much more positive and inclusionary name?

I’ve always felt the alternative part of ALT.NET to be quite elitist, exuding the feeling of “we’re different to you and that makes us better”.

Lets look at the dictionary definition of alternative:

A situation which allows a mutually exclusive choice between two or more possibilities.

A choice between two or more mutually exclusive possibilities.

One of several mutually exclusive things which can be chosen.

It’s all about choosing between different things and can give the impression of “it’s our way or the wrong way”.

Progressive .NET (could be similarly shortened to PROG.NET) could soften the message of the ALT.NET movement whilst having the same meaning.

For contrast, lets look at the dictionary definition of progressive:

Favouring or promoting progress; advanced.

Gradually advancing in extent; increasing.

Promoting or favouring progress towards improved conditions or new policies, ideas or methods:
a progressive politician.
progressive business leadership.

Isn’t progression of the craft of software engineering what ALT.NET is all about?

To be a part of ALT.NET I get the impression that you have to have mastered IoC, xDD, etc. before you can become a member. PROG.NET gives an altogether softer face, whilst still having the same ideals:

Want to improve your software? So do we, come join in.

Isn’t a message like that going to help ALT.NET cross the chasm? Then again, some will say what's in a name?

Difference between AreEqual and AreSame

2009-05-06T15:00:00.001+01:00

This is a question I’ve been asked at work before and the answer is quite important as it can lead to tests mysteriously failing.

The difference between the two assertions are quite simple. Assert.AreSame checks that they are the exact same object, memory reference and all (in the case of .NET using ReferenceEquals). Assert.AreEqual checks that objectOne.Equals(objectTwo) will return true.

Here’s a simple example of how they will work with a sensible implementation of Equals.

    1 public class Example
    2 {
    3     private int variable;
    4 
    5     public Example(int variable)
    6     {
    7         this.variable = variable;
    8     }
    9 
   10     public override bool Equals(object obj)
   11     {
   12         if (obj is Example)
   13             return Equals(obj as Example);
   14 
   15         return base.Equals(obj);
   16     }
   17 
   18     private bool Equals(Example obj)
   19     {
   20         return variable == obj.variable;
   21     }
   22 }
   23 
   24 [TestFixture]
   25 public class Test
   26 {
   27     [Test]
   28     public void ExampleTest()
   29     {
   30         var one = new Example(1);
   31         var two = new Example(1);
   32         var three = new Example(2);
   33         var four = one;
   34 
   35         Assert.AreEqual(one, two);   // true
   36         Assert.AreSame(one, two);    // false
   37         Assert.AreEqual(two, three); // false
   38         Assert.AreSame(two, three);  // false
   39         Assert.AreEqual(one, four);  // true
   40         Assert.AreSame(one, four);   // true
   41     }
   42 }

So long as you have a sensible Equals method that compares the values of the two objects you can follow these rules:

If two objects are the same, they will be equal
If two objects are equal, they may not be the same
If two objects are not equal, they will not be the same

So now you’ll know the answer next time someone asks what the difference between Assert.AreEqual and Assert.AreSame is.

Related posts: