Current Version is 1.0.1.16. You can download it here or get the latest sources from the trunk.

Happy specifying . . .

The biggest addition is the new ReportGenerator

I’ve wanted this for quite a while now but never really found the time to implement it. After running the RunBuild.cmd in the "Build" folder of the trunk you’ll find the .exe in the "Deploy" folder. It’s still a bit raw but exactly what I need for my current client (yes, you heard right. xUnit.BDDExtensions is currently being picked up at my current client )

Here are the current console arguments:

/assembly configures the spec assembly to extract a report from one or more assemblies.

ReportGenerator.exe /assembly:SomeSpecAssembly
ReportGenerator.exe /assembly:C:\Test\SomeSpecAssembly.dll
ReportGenerator.exe /assembly:’C:\Path with spaces\SomeSpecAssembly.dll’ ReportGenerator.exe /assembly:SomeSpecAssembly /assembly:SomeOtherSpecAssembly

/generator configures the generator to use. There are currently two generators implemented. One building an ASCII .txt file which looks like this. In order to use it you have to run the generator with

ReportGenerator.exe /assembly:SomeSpecAssembly /generator:Text

The other creating an HTML file which looks like this. This is the default generator which is used when you omit the /generator argument.

The files created by the generator are created on a per assembly basis and named like the assembly with the suffix .html or .txt. By default they are created in the same directory the generator is run from.

You can change this by configuring a different folder via /path.

ReportGenerator.exe /assembly:C:\Test\SomeSpecAssembly.dll /path:C:\temp

The deployment has changed slightly

The build script now merges xUnit.BDDExtensions to a single assembly (the external Rhino.Mocks assembly is not needed any more). Same applies to the ReportGenerator which uses StructureMap and NVelocity internally.

Some small changes to the API

• Dependency<TDependency>() has been marked as obsolete in InstanceContextSpecification<T> and StaticContextSpecification.
• AutoDependency<TDependency>() has been marked as obsolete in InstanceContextSpecification<T>.
• An<TDependency>() and Some<TDependency>() have been added to both InstanceCOntextSpecification<T> and StaticContextSpecification.
• The<TDependency>() has been added to InstanceCOntextSpecification<T>,

Its mostly naming which has been changed. Some discussions at my current client made me realize that
it’s easier to describe the behavior of xUnit.BDDExtensions to developers who haven’t used the tool before with An<ICar>() in favor of Dependency<ICar>() and The<ICar>() in favor of AutoDependency<ICar>().

An<TDependency>() returns a new dynamic stub object every time it’s called. The<TDependency>() behaves differently. BDDExtensions has AutoMocking support built-in. Once you let the framework create your test object you’re able to access the automatically injected dynamic stubs with this method. Last but not least Some<TDependency>() provides the same behavior as An<T>(). It only returns a collection of newly created stub objects.

I’m going to write a more detailed documentation of the current version soon. So in case you’re interested in the BDDExtensions, stay tuned . . .

As you might know xUnit.BDDExtensions is using Rhino.Mocks behind the scenes, but hides a lot of the mechanics of the library. This was done in order to eliminate a lot of the ceremony in a specification, so that a writer of a specification could focus on its essence (Quote MASHUP from JP and Jeremy D. Miller ). However, especially when configuring and verifying behaviors Rhino.Mocks still shines through (with all its power).

So let’s take a closer look at the problem I’m referring to. It has to do with specifications which observe indirect outputs. The following code is part of a little object-to-object-mapper I wrote some months ago.

public class ExpressionBasedWriter<Target, PropertyType> : IWriteStrategy<Target>
{
	private readonly IExpressionHandler expressionHandler;
	private readonly MemberExpression memberExpression;

	public ExpressionBasedWriter(
		Expression<Func> memberSelector,
		IExpressionHandler expressionHandler)
	{
		this.memberExpression = (MemberExpression) memberSelector.Body;
		this.expressionHandler = expressionHandler;
	}

        public void WriteTo(Target instance, object value)
	{
		expressionHandler.Handle(new HandlerContext
                {
                      TargetInstanceType = instance.GetType(),
                      TargetInstance = instance,
                      ValueToWrite = value,
                      MemberSelector = memberExpression
                });
	}
}

It’s not so important to understand the full context of the code. The important part is in the body of the WriteTo() method. Do you see it? It constructs an instance and passes it into an internal dependency. The interesting question now is how to verify the indirect output passed to the dependeny in a spec…

Take 1: Overriding Equals and GetHashcode() in the indirect output class.

In case you correctly implemented both of these methods you could write a spec, that looks like somewhat like this.

    [Concern(typeof(ExpressionBasedWriter<,>))]
    public class When_something_is_about_to_be_written : InstanceContextSpecification<IWriteStrategy<TestDto1>>
    {
        private IExpressionHandler expressionHandler;
        private Expression<Func> targetExpression;
        private TestDto1 target;
        private string valueToWrite;

        protected override void EstablishContext()
        {
            targetExpression = x => x.StringProperty;
            expressionHandler = Dependency();
            target = new TestDto1();
            valueToWrite = "uninteresting value";
        }

        protected override IWriteStrategy CreateSut()
        {
            return new ExpressionBasedWriter(targetExpression, expressionHandler);
        }

        protected override void Because()
        {
            Sut.WriteTo(target, valueToWrite);
        }

        [Observation]
        public void should_form_a_context_and_pass_it_to_the_actual_expression_handler()
        {
            expressionHandler.WasToldTo(x => x.Handle(new HandlerContext
            {
                MemberSelector = (MemberExpression)targetExpression.Body,
                TargetInstance = target,
                TargetInstanceType = target.GetType(),
                ValueToWrite = valueToWrite
            }));
        }
    }

This works. Ok, but what I don’t like about this solution is that I expose the concrete HandlerContext class to the spec. Test isolation is broken here. Besides I have to be very carefully with my implementation of Equals in this case, although it might only be needed in the specification.

Take 2: Introduce a factory

You can prevent the direct exposure of the specification to the concrete HandlerContext by introducing a factory which abstacts the creation of the HandlerContext class away.

	public class ExpressionBasedWriter<Target,PropertyType> : IWriteStrategy<PropertyType>
	{
		private readonly IExpressionHandler expressionHandler;
		private readonly IHandlerContextFactory handleContextFactory;
		private readonly MemberExpression memberExpression;

		public ExpressionBasedWriter(
			Expression<Func> memberSelector,
			IExpressionHandler expressionHandler,
			IHandlerContextFactory handleContextFactory)
		{
			this.memberExpression = (MemberExpression) memberSelector.Body;
			this.expressionHandler = expressionHandler;
			this.handleContextFactory = handleContextFactory;
		}

		public void WriteTo(Target instance, object value)
		{
			var context = handleContextFactory.CreateContext(memberExpression, instance, value);
			expressionHandler.Handle(context);
		}
	}

	[Concern(typeof (ExpressionBasedWriter<,>))]
	public class When_something_is_about_to_be_written :
		InstanceContextSpecification<IWriteStrateg<TestDto1>>
	{
		private IExpressionHandler expressionHandler;
		private IHandlerContext handlerContext;
		private IHandlerContextFactory handlerContextFactory;
		private TestDto1 target;
		private Expression<Func> targetExpression;
		private string valueToWrite;

		protected override void EstablishContext()
		{
			targetExpression =  x => x.StringProperty;
			expressionHandler = Dependency();
			handlerContextFactory = Dependency();
			handlerContext = Dependency();

			target = new TestDto1();
			valueToWrite = "uninteresting value";

			handlerContextFactory.WhenToldTo(x => x.CreateContext((MemberExpression)targetExpression.Body, target, valueToWrite)).Return(handlerContext);
		}

		protected override IWriteStrategy CreateSut()
		{
			return new ExpressionBasedWriter(targetExpression, expressionHandler, handlerContextFactory);
		}

		protected override void Because()
		{
			Sut.WriteTo(target, valueToWrite);
		}

		[Observation]
		public void should_call_the_context_handler_factory_in_order_to_create_a_context()
		{
			handlerContextFactory.WasToldTo(x => x.CreateContext((MemberExpression)targetExpression.Body, target, valueToWrite));
		}

		[Observation]
		public void should_call_the_expression_handler_in_order_to_handle_the_created_context()
		{
			expressionHandler.WasToldTo(x => x.Handle(handlerContext));
		}
	}

Again, this works too. But is that really a path one should go? Introducing an additional factory + interface everytime one encounters an indirect output? Besides that, did you notice how the specification kind of degraded? So much additional noise now in there. This one causes me actually more pain than Take 1, which takes me to …

Take 3: A neat Rhino.Mocks feature

Leave the code from Take 1 as it is. Here’s how you can write the specification, without exposing it to the concrete HandlerContext class and without causing to much noise in the specification itself.

    [Concern(typeof(ExpressionBasedWriter<,>))]
    public class When_something_is_about_to_be_written : InstanceContextSpecification<IWriteStrategy<TestDto1>>
    {
        private IExpressionHandler expressionHandler;
        Expression<Func> targetExpression;
        private TestDto1 target;
        private string valueToWrite;

        protected override void EstablishContext()
        {
            targetExpression = x => x.StringProperty;
            expressionHandler = Dependency();
            target = new TestDto1();
            valueToWrite = "uninteresting value";
        }

        protected override IWriteStrategy CreateSut()
        {
            return new ExpressionBasedWriter(targetExpression, expressionHandler);
        }

        protected override void Because()
        {
            Sut.WriteTo(target, valueToWrite);
        }

        [Observation]
        public void should_form_a_context_and_pass_it_to_the_actual_expression_handler()
        {
            	expressionHandler.WasToldTo(x => x.Handle(Arg<IHandlerContext>.Matches(matcher =>
                       matcher.MemberSelector == targetExpression.Body &&
                       matcher.TargetInstance == target &&
                       matcher.TargetInstanceType == target.GetType() &&
                       matcher.ValueToWrite.Equals(valueToWrite))));
        }
    }

The interesting stuff happens around the generic Arg class. You can use it to specify a callback with which the indirect output can be verified.

Conclusion

In the past I mostly did what I demonstrated with Take 1 when I encountered a situation where I needed to verify indirect outputs. Introducing a factory for this was never really an option for me. I don’t see a real benefit there. The generic argument matching capabilities of Rhino.Mocks really close a gap for me and they’re what I’m going to use for solving similar situations from now on.

I hope I’m not the only kid on the street who didn’t know that this feature exists . . .

This little feature was added to the trunk today. Yes, no CreateSut() call. You can omit it for most of the simple scenarios. You can still override it, if you need/have to. It uses the AutoMocking capabilities of StructureMap internally.

I’m going to merge the different involved assemblies to a single assembly soon in order to make deployment a bit easier . . .

require 'rake/clean'

EXTERNALS_DIR = File.expand_path('../Externals')
BUILD_DIR = File.expand_path('../Bin')
SOURCE_DIR = File.expand_path('../Source')

CLEAN.include(FileList[File.join(BUILD_DIR, '*')])

desc "Compiles the gemini sources"
task :build do
  gemini_solution =  File.join(SOURCE_DIR, 'Gemini.sln')
  sh "msbuild /property:WarningLevel=4;OutDir=#{BUILD_DIR}/  #{gemini_solution}"
end

desc "Runs all the tests on the gemini code"
task :test do
  assemblies = all_spec_assemblies()
  xunit_console = File.join(EXTERNALS_DIR, "xUnit/xunit.console.exe")

  assemblies.each do |assembly|
    sh "#{xunit_console} #{assembly} /html #{assembly +'.UnitTests.html'}"
  end
end

task :default => [:clean, :build, :test]

def all_spec_assemblies()
  file_mask = File.join(BUILD_DIR, '*Specs.dll')
  FileList[file_mask]
end

I think this code demonstrates the qualities of Ruby as a scripting language and Rake as a build tool really well. It’s very descriptive and even more important it doesn’t have all the xml-slash-what-the-hell-is-going-on-here-noise around it. I know it’s a very simple solution, but I consider it a good start. Let’s look a bit more detailed at the parts of the script.

EXTERNALS_DIR = File.expand_path('../Externals')
BUILD_DIR = File.expand_path('../Bin')
SOURCE_DIR = File.expand_path('../Source')

This part defines some directory constants that are used in the script. The rakefile is currently run from the directory ‘Build’ which is on the same level as ‘Externals’, ‘Bin’ and ‘Source’. Relative paths are expanded to absolute paths here.

CLEAN.include(FileList[File.join(BUILD_DIR, '*')])

This tiny little code piece modifies the built-in :clean task and adds all files under the BUILD_DIR to it.
Running ‘rake clean’ on the console will now delete all files from our build directory.

desc "Compiles the gemini sources"
task :build do
  gemini_solution =  File.join(SOURCE_DIR, 'Gemini.sln')
  sh "msbuild /property:WarningLevel=4;OutDir=#{BUILD_DIR}/  #{gemini_solution}"
end

This is the first task I’ve actually written on my own. It’s only a very small wrapper around msbuild that builds the solution file.

desc "Runs all the tests on the gemini code"
task :test do
  assemblies = all_spec_assemblies()
  xunit_console = File.join(EXTERNALS_DIR, "xUnit/xunit.console.exe")

  assemblies.each do |assembly|
    sh "#{xunit_console} #{assembly} /html #{assembly +'.UnitTests.html'}"
  end
end

def all_spec_assemblies()
  file_mask = File.join(BUILD_DIR, '*Specs.dll')
  FileList[file_mask]
end

That little code is a small wrapper around xUnit.net which invokes the xunit.console.exe for each file
it finds in the build directory that ends with ‘Spec.dll’. These are the assemblies which contain the BDD-style tests in our project.

task :default => [:clean, :build, :test]

This last piece defines the :default build task. That’s the task which is run when you don’t specify a task directly when running rake from console. This will run all tasks in the order specified from left to right.

Conclusion

The Rake build engine rocks !!! Its really simple and descriptive API is fun and Rake doesn’t create a lot of ceremony around build scripts (Only around 30 lines of code in my current script). However, you should be aware of one thing: Coming from a language with a lot of IDE support (like C# in my case) to Ruby might not be as easy as it sounds. It took me quite a while to make the transition from Intellisense and Resharper to using IRB and reading RDoc in order to explore new APIs . . .

What bothers me lately is that this style mixes context and behavior under test into one fixture class name, which can be extremely long because of that. An example to clarify what I mean:

 public class When_adding_a_contact_to_a_user_with_no_existing_contacts { }
 

“Adding a contact” is the observed behavior in the context of “no existing contacts”. I believe
this should be more obvious, which made me thinking of how a syntax for this could look like.

Having said that, here is what I came up with. It’s heavily inspired by MSpec and RBehave.

[SpecificationFor(typeof(PatientService))]
public class A_patient_with_a_missing_first_name_is_not_allowed_to_be_persisted
{
      Given a_patient_with_a_missing_first_name = () =>
      {
      };

      When trying_to_save_the_patient = () =>
      {
      };

      It should_not_persist_the_supplied_patient = () =>
      {
      };

      It should_return_a_report_indicating_that_the_patients_first_name_is_required = () =>
      {
      };
}

A generated report for this code might look like this:

Specifications for “PatientService”

• A patient with a missing first name is not allowed to be persisted
  • Given a patient transfer object with a missing first name
  • when trying to save the patient
    • it should not persist the supplied patient
    • it should return a report indicating that the patients first name is required
      

I’m still not 100% happy with this, because there is some sort of duplication between the fixture name and the “givens” (at least in the shown example), but with this approach you

1. are able to separate context and behavior in a clean way,
2. can describe the context very fine grained (by having multiple “givens”)
3. and besides that it looks cool

I would like to hear opinions on that. Is this something worth implementing / adding to xUnit.BDDExtensions?
Or am I off the track with this?

xUnit.BDDExtensions is a little framework build on top of xUnit which enables a BDD style of testing with xUnit.

Besides an emphasis on a “test case class per fixture” organization scheme for tests, AAA (Arrange, Act and Assert) style of writing tests and left to right assertions, this framework also provides Rhino.Mocks integration out of the box. By hiding the mechanics of Rhino.Mocks (record and replay model, mocks vs. stubs) behind the scenes, xUnit.BDDExtensions also helps on writing cleaner, easier to understand and less brittle tests

xUnit.BDDExtensions is based on JP Boodhoos BDD extensions for MBUnit used in his “Nothing but .NET” bootcamps.

Enough of the talking, let’s look at some code

This is actual code of the xUnit.BDDExtensions trunk. The SpecificationTestCommand class serves as a kind of adapter inside xUnit. It enables the test class to have methods that are run before and after the actual test method is executed.*

    public class SpecificationTestCommand : BeforeAfterCommand
    {
        public SpecificationTestCommand(
            ITestCommand innerCommand,
            MethodInfo testMethod)
            : base(innerCommand, testMethod)
        {
        }

        public override MethodResult Execute(object testClass)
        {
            var specification = testClass as ITestSpecification;

            try
            {

                if (specification == null)
                {
                    throw new InvalidOperationException(
                          "Instance does not implement ITestSpecification");
                }

                specification.InitializeSpecification();
                return base.Execute(testClass);
            }
            finally
            {
                if (specification != null)
                {
                    specification.CleanupSpecification();
                }
            }
        }
    }

Notice several things:

1. It expects the instance to implement ITestSpecification.
2. It calls the InitializeSpecification() method on it
3. Passes the execution to the inner command (in base.Execute(obj))
4. and finally cleans up the specification by calling CleanupSpecification() on it.

So how can a completely isolated happy path test for this look like?

 [Concern(typeof(SpecificationTestCommand))]
 public class when_a_specification_test_command_is_executed_on_a_ITestSpecification_implementer :
        concern_for_specification_test_command
    {
        private MethodResult expectedTestResult;
        private ITestCommand innerCommand;
        private MethodInfo methodInfo;
        private MethodResult testResult;
        private ITestSpecification testSpecification;

        protected override void EstablishContext()
        {
            innerCommand = Dependency();
            testSpecification = Dependency();
            methodInfo = GetTestMethodHandle();
            expectedTestResult = CreateMethodResult(methodInfo);

            innerCommand.WhenToldTo(x => x.Execute(testSpecification))
                     .Return(expectedTestResult);
        }

        protected override SpecificationTestCommand CreateSut()
        {
            return new SpecificationTestCommand(innerCommand, methodInfo);
        }

        protected override void Because()
        {
            testResult = Sut.Execute(testSpecification);
        }

        [Observation]
        public void should_ask_the_test_specification_to_initialize()
        {
            testSpecification.WasToldTo(x => x.InitializeSpecification());
        }

        [Observation]
        public void should_pass_the_test_specification_to_the_inner_test_command()
        {
            innerCommand.WasToldTo(x => x.Execute(testSpecification));
        }

        [Observation]
        public void should_return_the_test_result_from_the_inner_test_command()
        {
            testResult.ShouldBeEqualTo(expectedTestResult);
        }

        [Observation]
        public void should_ask_the_test_specification_to_cleanup()
        {
            testSpecification.WasToldTo(x => x.CleanupSpecification());
        }
    }

Notice several things:

1. In the EstablishContext() method the whole context for the test is created. This includes creating most of the dependencies with Rhino.Mocks through Dependeny() and the necessary configuration of their behavior. This is done in order to quickly get from an interaction based style of testing to a state based style of testing. In AAA terms this method implements the Arrange part.
2. The CreateSut() method is executed after EstablishContext() and creates the actual system under test.
3. The Because() method implements the actual behavior under test. In AAA terms this is the Act part. In the current example this meant executing the test command with an instance implementing the expected interface.
4. Each method marked with the ObservationAttribute contains a single observation which should be fulfilled when the test has been executed. In AAA terms every Observation is an Assert.

That’s basically it. Pretty straight forward imho. If I managed to make you at least a bit curious about this style of testing, you can grab the source with any Subversion client from:

http://xunitbddextensions.googlecode.com/svn/trunk/

Enjoy coding

*
I know xUnit dropped this behavior in favor of the dispose pattern, but having explicit, non technically named methods for that still seems more natural in the context of BDD to me.

So here it is. Any feedback is appreciated . . .

A short description of my problem

I’m using a test-case-class-per-fixture organization and the template method pattern for writing tests in the AAA scheme. Besides that I use a specialized FactAttribute in order to invoke my AAA – hook methods in the correct order. All of this is residing in a separate assembly.

When I use the build-in FactAttribute to mark my tests alll tests are discovered by the Resharper’s TestExplorer, but when I’m using my own marker attributes nothing is discovered.

What seems to be the problem

It took me some time to find out what was actually going on. I’ve never debugged a Resharper-Plugin before. This helped a lot. It was an interesting experience, though. Didn’t knew that there is so much going on behind the scenes. This is what I found out:

• The XUnitTestProvider class is responsible for discovering tests.
• It skips all assemblies which don’t reference xunit directly.

Hm, I had a reference to xunit in my test library project settings. However I was not referencing xUnit stuff from my code directly (Own FactAttribute and xunitext35 extension methods for assertions). That’s when it hit me:

My problem was probably caused by a compiler optimization. It seems that all unused assembly references are removed when building the test assembly. A look into reflector supported my thesis. So my test assembly has no direct reference to the xunit.dll, only an indirect one through the BDD framework.

Patching this is quite easy

This is the original method:

static bool IsTestAssembly(IMetadataAssembly assembly)
{
        foreach (AssemblyReference reference in assembly.ReferencedAssembliesNames)
               if (reference.AssemblyName.Name.ToLowerInvariant() == "xunit")
                     return true;

        return false;
}

When changing this a bit to this, everything runs as expected.

static bool IsTestAssembly(IMetadataAssembly assembly)
{
        foreach (AssemblyReference reference in assembly.ReferencedAssembliesNames)
        {
              string assemblyName = reference.AssemblyName.Name.ToLowerInvariant();

              if (assemblyName.StartsWith("xunit"))
                   return true;
       }

       return false;
}

All tests are discovered and I’m quite happy that I can use BDD, XUnit and Resharper in combination

One thing to be aware of: In order to get the tests not only discovered but also executed in Resharper you’ll have make sure that your test project and the Resharper addin are both using the same, exact version of xUnit. I stumbled over this after I recompiled and installed my patch on my machine. Resharper is not able to execute the tests in case of a version mismatch.

Some of the things I really like about it:

• It has a set of .NET 3.0 Extension methods, which can be used instead of classic assertions (f.e.: “Foo”.ShouldNotBeNull() )
• It runs every every test on a separated instance.
• It uses the constructor of the test class and the Dispose-pattern for fixture initialization and release of resources after a test.
• It’s relatively easy to extend XUnit.

Because of curiosity and my current affection with BDD I decided to port the BDDExtension stuff from  JP Boodhoo to XUnit. So here we go:

Marking specifications with concerns

All specifications for a particular type are marked with the ConcernAttribute.  This is only a marker attribute by which a tool like bddunit is able to correlate specifications and their related type.

[AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]
public class ConcernAttribute : TraitAttribute
{
        private readonly Type _Type;

        public ConcernAttribute(Type type) : base("Concern", type.FullName)
        {
                _Type = type;
        }

        public Type Type
        {
                get { return _Type; }
        }
}

The ConcernAttibute extends the TraitAttribute which is described in the documentation as “an Attribute used to decorate a test method with arbitrary name/value pairs (“traits”).” I changed the AttributeTarget from method to class in order to suit my needs.

Changing the way the test is executed

JP’s original code relied on the SetUp and Teaddown handlers of NUnit / MBUnit which are execute before and after each test method in the same class. Since XUnit doesn’t have that feature any more we’ll have to extend it a bit.

The main extension point for how a test is executed is the FactAttibute used to mark a method as a test. You can extend it and return a different ITestCommand which is then used to execute the test.

public class ObservationAttribute : FactAttribute
{
        protected override IEnumerable EnumerateTestCommands(MethodInfo method)
        {
                var testCommand = base.EnumerateTestCommands(method).First();
                yield return new SpecificationTestCommand(testCommand, method);
        }
}

Do you wonder why the method returns an IEnumerable<ITestCommand>? This is done in order to support something like row tests in MBUnit. The XUnit framework basically enables you to run a test several times. For me this isn’t interesting so I just grabbed the first ITestCommand from it and wrapped it with my own implementation, which looks like this:

public class SpecificationTestCommand : BeforeAfterCommand
{
        public SpecificationTestCommand(
                ITestCommand innerCommand,
                MethodInfo testMethod)
                : base(innerCommand, testMethod)
        {
        }

        public override MethodResult Execute(object testClass)
        {
                var specification = testClass as IContextSpecification;

                if (specification == null)
                {
                       throw new InvalidOperationException(
                          "Instance does not implement IContextSpecification");
                }

                try
                {
                        specification.EstablishContext();
                        specification.Because();
                        return base.Execute(testClass);
                }
                catch(AssertException)
                {
                        throw;
                }
                catch (Exception exception)
                {
                        ExceptionUtility.RethrowWithNoStackTraceLoss(exception.InnerException);
                }

                return null;
        }
}

The code requires the test class to implement the IContextSpecification interface in order to invoke the EstablishContext() and Because() methods for doing AAA based tests. (Do you miss AfterEachSpec? One moment please ) For every interface there is a base class which is in my case the ContextSpecification class.

public abstract class ContextSpecification : IContextSpecification, IDisposable
{
      protected abstract void Because();

      protected abstract void EstablishContext();

      protected virtual void AfterEachSpec()
      {
      }

      #region IContextSpecification Members

      void IContextSpecification.Because()
      {
            Because();
      }

      void IContextSpecification.EstablishContext()
      {
            EstablishContext();
      }

      #endregion

      #region IDisposable Members

      public void Dispose()
      {
            AfterEachSpec();
      }

      #endregion
}

Notice some things. AfterEachSpec() is called from Dispose(), That’s why I didn’t need to include it into the IContextSpecification interface. That interface is implemented explicitly in order to allow the hooks to have different modifiers (protected).

A first test

There’s always an interesting moment when you first run your little experiment. Here we go:

[Concern(typeof(Factory))]
public class When_creating_product_with_a_valid_name : ContextSpecification
{
      private Factory _Factory;
      private Product _CreatedProduct;

      protected override void EstablishContext()
      {
            _Factory = new Factory();
      }

      protected override void Because()
      {
            _CreatedProduct = _Factory.Create("Foo");
      }

      [Observation]
      public void The_product_should_contain_the_correct_name()
      {
            _CreatedProduct.Name.ShouldEqual("Foo");
      }

      [Observation]
      public void The_product_should_contain_the_correct_vendor_name()
      {
            _CreatedProduct.VendorName.ShouldEqual("FooVendor");
      }
}

And the result from TestDriven.NET is:

—— Test started: Assembly: Xunit.BddExtensions.Samples.dll ——
2 passed, 0 failed, 0 skipped, took 0,92 seconds.

Conclusions

It’s in fact very easy to extend XUnit. I like the tool even more after doing this little research. The shown code runs smoothly with TestDriven.NET. However the Resharper – TestRunner seems to have problems with it (TestExplorer stays blank).

I’ll play with that approach in the next few weeks and will blog about my experience with both XUnit and BDD. So if you’re interested in more stay tuned . . .

P.s.: If you’re interested in the code, just drop me a line . . .