Rhino ESB for Dummies

This will document my “dummy” experience. I’ve been using NServiceBus for a while, but the license model changed out from under us so we’ve been investigating alternatives. A fellow in the office pointed us to Rhino ESB (he had pointed us to NServiceBus earlier).

Immediate Impressions

• SNAP – I need to get GIT running in the desktop (git v1.7.3.5)
• Brought up a new command window and typed:
• git clone https://github.com/ayende/rhino-esb.git
• Had to figure out how to use psake

C:\Source\external\rhino-esb>powershell
Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.

PS C:\Source\external\rhino-esb> .\psake.ps1 .\default.ps1

So, that appears to be all there is to it.

Upsides/Downsides

• We’ve been making extensive use of Autofac as our container and Rhino has a predisposition for Castle Windsor. We’ll just use Windsor in the handlers for now and leave other areas (i.e. ASP.NET MVC 2) to use Autofac. I’m told that a container agnostic version of Rhino ESB is in the works.
• Testing with NServiceBus was pretty straightforward as it provided mocks of our handlers and also setup the expect portions. I’m told that with Rhino Mocks we don’t need to worry about that and we just test our handler’s independently from the ‘service bus’.
• No more need to adorn our message classes with IMessage.

UPDATE

I had to enter Set-ExecutionPolicy Unrestricted to run the psake script.

Separating Integration Tests from Unit Tests with xUnit

How often do you find that you’ve written a very useful test that crosses a process boundary, or makes changes to another system (file system, database) which by definition of a Unit Test shouldn’t be tested as part of your code coverage, but its highly useful.

Here are some attributes that you can use to mark up your (these are inspired by several other posts out there on the internet).

public sealed class IntegrationFactAttribute : FactAttribute
{
   protected override IEnumerable EnumerateTestCommands(IMethodInfo method)
   {
       var attrs = method.MethodInfo.GetCustomAttributes(typeof(IntegrationAttribute), true).Cast();

       if (Skip == null && attrs.Any(x => x.ShouldRunTest))
       {
           return base.EnumerateTestCommands(method);
       }

       return new[] { new SkipCommand(method, method.Name, "Integration method skipped") };
   }
}

The abstract class below defines a simple Boolean property in which we can define the circumstances under which we want to execute the method.

public abstract class IntegrationAttribute : Attribute
{
   public abstract bool ShouldRunTest { get; }
}

Below is an example class that tests to see if there is a debugger attached, and if so, it returns true for the ‘ShouldRunTest’ property. When this is evaluated in the EnumerateTestCommands in the IntegrationFactAttribute it will run the marked test method.

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false)]
public class WhenInDebuggerAttribute : IntegrationAttribute
{
   public override bool ShouldRunTest
   {
       get { return System.Diagnostics.Debugger.IsAttached; }
   }
}

Example using both attributes. This test which tests through to the database will only be run if it was executing inside of the debugger. If you are using Resharper or TestDriven.NET then you can execute the test while debugging but no longer need to worry need to be concerned that your continuous build environment will be testing code depends on a shared resource.

[IntegrationFact, WhenInDebugger]
public void CheckLiveRepositoryOnClinicianByOrganizationID()
{
   const int idToMatch = 1;

   // Create LS2 Repository
   var repository = CreateRepository();

   // Use a Specification to retrieve results
   var clinicians = repository.Find(ClinicianSpecs.ByOrganizationID(idToMatch)).ToList();

   // Assert valid
   clinicians.Should().Not.Be.Null();
}

Note that I’m using the Should Assertion Library instead of the Assert.NotNull(). If you’re interested in more behavior driven development then this library makes your assertions read well.