Introducing SpecMaker “Rspec style” BDD in C#


So I’m certain this will be met with mixed response, because really .Net already has several decent BDD frameworks and many of you will chastise me for adding yet another framework when really BDD has nothing to do with what testing framework you use.  So why you ask?

  1. Most of the BDD frameworks I’ve looked at are Acceptance style and trying to make stories into executable code (NBehave, StoryTeller, Fitnesse.Net ,Acceptance, etc).  I want something that describes to other developers in a behavior centric way what my code is doing (like RSpec’s default DSL does).  This is not aimed at business analysts.
  2. The other RSpec style framework for C# I’ve played with while very nice, did not go over well with people I’ve tried to introduce to BDD.
  3. Using NUnit in a context BDD style is normally what I do but produces a lot of artifacts, is underscore heaven and provides no guidance to newer practitioners of BDD.

With all this in mind how does SpecMaker improve our situation at all?  First lets look at how I might approach a BDD test with NUnit

   [TestFixture]
    public class SpecGameWhenStartingUp
    {
      
        private Game _game;
        private void startGame(){
           // left out for clarity
        }
        [SetUp]
        public override void SetUp()
        {
           startGame();            
        }
        [Test]
        public void should_have_3_lives()
        {
           Assert.AreEqual(3, _game.lives);
        }
     }

On the surface there isn’t much wrong with this. Asserts are less than ideal (Rspec matchers would be nice), underscores on my “should_” are so so, context in the class name leads to lots of classes and me playing around a bunch with inheritance. However, none of this is a game breaker and for those of you who have a good workable flow with this approach and are happy with it, please continue to use it. I however, am not happy with the flow, also BDD really is not easy for me to teach. Some of you may get it easily and teach it easily, but .Net developers as a whole seem to be driven towards framework specific knowledge (telling them to not think “test” when test is staring at them on the method messes with their heads), and even then it’d better not be too “cutting edge” in language features or friction becomes a risk where someone may end up learning more than just BDD.

So what are my goals then for SpecMaker?

  1. It has to be terse, and be shorter than the NUnit approach.
  2. Eliminate underscores where possible.
  3. Act as a series of guidelines to beginning BDD’ers.
  4. Output spec results in a variety of formats.
  5. Remove the “Test” entirely from the vocabulary.
  6. Use convention over configuration where possible.
  7. Provide custom matchers and a DSL to make your own custom matchers.

What will it not do or be?

  1. Do acceptance testing. This could change in the future, but then I’d be inclined to borrow code from others that do this well already.
  2. Make BDD a “click next” thing. There is no substitute for continually trying to refine your approach and understand “behavior” and what that means. I’m not sure there is one true right answer here and that makes it so incredibly hard to make a framework that does that.
  3. Be as nice as RSpec.
  4. Integration tests. This is setup very much one-to-one. Again this was a simplicity choice and as I dog food this I may completely change my mind here.

So with all the ceremony out of the way here is where I’m at so far for the same BDD code above only with SpecMaker

 public class GameSpec : BaseSpec
    {
        private void startGame(){
          //left out for clarity
        }  
        public void when_starting_a_game()
        {
            startGame();
            should(“have 3 lives”, ()=>
                    {
                       _game.lives.Has(3).Total();
                    }
                );
            should(“require valid username”, RuleIs.Pending);
        }
     }

Running specmaker.exe on the the dll where this spec is located outputs something like this:

Picture 2

 

 

At this time specs come from the class name minus “Spec” at the end. Context start with “when” or the method will not get picked up as context.  This is also staggeringly new and may have bugs, issues, bad docs, ugly code, etc. But since I’ve moved this to Github I encourage everyone to have a go and improve it as they see fit or for their own purposes.  I have a number of plans and ideas to improve this, but I feel this is a good start to get some positive work done and save myself some grief over my NUnit based tests.

Let me know what you think, any and all criticism is appreciated, but at the end of the day this does actually fulfill an itch that I myself have had for some time.

Windsor style convention over configuration in StructureMap