login      my ps      about      contact  



home instructor-led on-demand! screencasts blogs technical staff


David Starr » Some Alternative Ways of Reading Context/Specification

Some Alternative Ways of Reading Context/Specification

I have been playing with BDD conventions for several days and while I am no expert, I genuinely enjoy the way this style forces me to consider design before creating code.

I have tried to catch up on all the BDD purse fights going on out there and I understand that there are passionate differences in the way people prefer to interact with their tests. That said, regardless of what verbiage is being used or I believe what we are really doing is

preparing to test / invoking the SUT / asserting what the SUT should have done

In that spirit, can someone tell me the difference between these 3 base classes used for unit tests?

using NUnit.Framework;
 
namespace RoboDojo.War.Specs
{
    public class ContextSpecification
    {
        [SetUp]
        public void MainSetup()
        {
            SetContext();
            Because();
        }
 
        [TearDown]
        protected void MainTeardown()
        {
            CleanUp();
        }
 
        protected virtual void CleanUp() { }
        protected virtual void Because() { }
        protected virtual void SetContext() { }
    }
 
    public class AAA
    {
        [SetUp]
        public void MainSetup()
        {
            Arrange();
            Act();
        }
 
        [TearDown]
        protected void MainTeardown()
        {
            CleanUp();
        }
 
        protected virtual void Act() { }
        protected virtual void Arrange() { }
        protected virtual void CleanUp() { }
    }
 
    public class GWT
    {
        [SetUp]
        public void MainSetup()
        {
            Given();
            When();
        }
 
        [TearDown]
        protected void MainTeardown()
        {
            CleanUp();
        }
 
        protected virtual void When() { }
        protected virtual void Given() { }
        protected virtual void CleanUp() { }
    }
 
}

If there is a big difference there I am not seeing it.

What do the tests themselves look like?

using System;
using NUnit.Framework;
using RoboDojo.Core.BattleField;
using RoboDojo.War.Combat;
 
namespace RoboDojo.War.Specs.Combat_BattleMap
{
    [TestFixture]
    public class When_an_item_is_added : ContextSpecification
    {
        private BattleMap _battleMap;
        private MapFeature _feature;
 
        protected override void SetContext()
        {
            _battleMap = Mother.CreateAnEmptyBattleMap();
            _feature = new MapFeature(0, 0, Guid.NewGuid());
        }
 
        protected override void Because()
        {
            _battleMap.Add(_feature);
        }
 
        [Test]
        public void it_should_appear_on_the_map()
        {
            _battleMap.Exists(_feature.ID).ShouldBeTrue();
        }
 
        [Test]
        public void it_should_be_retrievable_from_the_map()
        {
            _battleMap.Find(_feature.ID).ID.ShouldEqual(_feature.ID);
        }
    }
 
    [TestFixture]
    public class When_an_item_is_added_2 : AAA
    {
        private BattleMap _battleMap;
        private MapFeature _feature;
 
        protected override void Arrange()
        {
            _battleMap = Mother.CreateAnEmptyBattleMap();
            _feature = new MapFeature(0, 0, Guid.NewGuid());
        }
 
        protected override void Act()
        {
            _battleMap.Add(_feature);
        }
 
        [Test]
        public void it_should_appear_on_the_map()
        {
            _battleMap.Exists(_feature.ID).ShouldBeTrue();
        }
 
        [Test]
        public void it_should_be_retrievable_from_the_map()
        {
            _battleMap.Find(_feature.ID).ID.ShouldEqual(_feature.ID);
        }
    }
 
    [TestFixture]
    public class When_an_item_is_added_3 : GWT
    {
        private BattleMap _battleMap;
        private MapFeature _feature;
 
        protected override void Given()
        {
            _battleMap = Mother.CreateAnEmptyBattleMap();
            _feature = new MapFeature(0, 0, Guid.NewGuid());
        }
 
        protected override void When()
        {
            _battleMap.Add(_feature);
        }
 
        [Test]
        public void it_should_appear_on_the_map()
        {
            _battleMap.Exists(_feature.ID).ShouldBeTrue();
        }
 
        [Test]
        public void it_should_be_retrievable_from_the_map()
        {
            _battleMap.Find(_feature.ID).ID.ShouldEqual(_feature.ID);
        }
    }
}

And how about the all important test runner view so that we can see the results of our tests? Can you tell which mental model produced which test?

image

So that last point is my point. The way you choose to think about your contextual configuration doesn’t need to be a slap fight, it is just how you think about it. I personally like to think in the GWT mental model and even apply it to my system components. So what?

There are some nice things people have come up with to reinforce their favorite mental model. SpecUnit for .NET is full of tasty morsels to be begged, borrowed, or stolen into your own tests.

The important thing, IMO, is that I can use these tests in a report to explain to my mom what my code is doing. And mom doesn’t code.

Posted Feb 27 2009, 12:14 AM by david-starr

Comments

Peter Seale wrote re: Some Alternative Ways of Reading Context/Specification
on 03-20-2009 11:41 AM

I've tried about a few of the frameworks (not SpecUnit though), and for simple setups, you're right--it's all pretty much the same. It's when you get to setting up more complex contexts, or at the least want to reduce duplication in your tests, is where I've seen a BIG improvement. I'm trying out Machine.Specifications right now and so far have had zero problems removing duplication.

I haven't blogged about the topic at all, because I'm still new to all this. But, even at this early stage I can claim victory on the DRY front--Machine.Specifications has provided a framework where I can BOTH eliminate all code duplication AND adhere to the context/specification style.

I probably shouldn't go into too much detail here in the comments, but I'll try to put forth a scenario:

* Simple context #1 (has a few private members)

* Slightly more complex context #2 (has exactly 1 additional member)

* Different, but also slightly more complex context #3 (has a different additional member)

Anyway, just take my word for it :)

Also great post! I wish I had found this when I started my own survey of the Context/Specification frameworks!

Colin Jack wrote re: Some Alternative Ways of Reading Context/Specification
on 03-26-2009 7:08 AM

I'm not sure we're doing GWT justice if we just have a Given method, apart from anything else its not visible in the output.

Personally I have a base class with overridable EstablishContext/Because methods which isn't that different, but even if I rename them Given and When its not the same style Dan North described (which I don't bother with for unit testing anyway).

Colin Jack wrote re: Some Alternative Ways of Reading Context/Specification
on 03-26-2009 7:14 AM

Oh and you might also find this thread interesting:

groups.google.com/.../2ef57e408fb38d0f


home instructor-led training online training blogs

781.749.9238 (East Coast) | 310.251.9901 (West Coast) | Pluralsight, LLC , 185 Lincoln St., Suite 305, Hingham, MA 02043-1741

Copyright © 2008 Pluralsight LLC. All rights reserved.

designed by nukeation