What the heck does that mean? Well, let’s say I get the following story:

    As a customer of our website
    When I order a medical product
    And I want it shipped to a state with no sales tax on medical products
    I should see that there is no tax for the item
    And no sales tax for that item should be incorporated in the final price

Quite a mouth full, yet completely contrived.

What does my executable specification for this look like? Well, first, let’s name it:

public class when_I_order_medial_products_for_shipment_to_places_where_they_arent_subject_to_sales_tax { }

I changed the wording around a little. I would probably work on this with a business expert to make sure I understood the story right. I might even come up with something more concise and understand the story/business even better from the conversation.

Next, the asserts:

It shows_me_there_is_no_sales_tax_for_the_item;It doesnt_include_any_tax_for_the_item_in_the_total;

Personally, I prefer writing my specs in active voice. It helps me get in the role of the person that we’re doing this for.

If I run this now, I get the “pending” behavior we talked about in my last post:

 when I order medial products for shipment to places where they arent subject to sales tax
 » shows me there is no sales tax for the item (NOT IMPLEMENTED)
 » doesnt include any tax for the item in the total (NOT IMPLEMENTED)

Before I can implement the assertions, I need to be able to build the context up:

Because of = () => {    // TODO: Shit...I don't know};

If you are used to test-first design, you are probably familiar with the concept of “write the code you wish you had.” Increasingly, I am finding, even if just for design purposes, the code I wish I had was wrapped in a fluent builder for the contexts I am testing:

Because of = () => {    var invoice = new Invoice()        .with_some_medical_product()        .shipping_to(new Address().where_medical_products_arent_taxed());};

That pretty much sums up the scenario I want. I just need to implement these extension methods.

public static class ContextBuilder{  public static Invoice with_some_medical_product(this Invoice invoice)  {      invoice.Items.Add(new InvoiceItem { });

      return invoice;  }}

So, what makes something a medical product in our system? Is it simply an attribute of a product?

invoice.Items.Add(new InvoiceItem {   Product = new Product { Category = Category.MedicalSupplies });

Or is there some service that figures that out?

static IProductCategoryFigureOuter categories = MockRepository.GenerateStub<IProductCategoryFigureOuter>();

public static Invoice with_some_medical_product(this Invoice invoice){    Product medicalProduct = new Product { };    categories.Stub(x => x.IsMedicalProduct(medicalProduct)).Return(true);

    invoice.Items.Add(new InvoiceItem {        Product = medicalProduct    });

    return invoice;}

We need to ask the SME/business expert more questions to figure out how best to represent this in our system.

How do we make an address where_medical_products_arent_taxed? Another service?

static ITaxInfoService taxInfo = MockRepository.GenerateStub<ITaxInfoService>();

public static Address where_medical_products_arent_taxed(this Address address){    taxInfo.Stub(x => x.AreMedicalProductsTaxedIn(address)).Return(false);

    return address;}

We’re starting to get close to where we are going to have to write some real code. Up until this point, all we’ve done is sketch out how it might look structurally, from a high level, but we’ve done this while keeping real business concerns in mind the whole time. Using fluent-style builders to help manage and create the context helped us do that and name the actors that make up the context. The problem is decomposing naturally into smaller problem.

If we’ve gotten good answers to the questions we surfaced during this process, chances are high that our application closely resembles the actual business we’re modeling.

I never really ended up using MSpec on things at work. There were lots of lame reasons:

• We were using MbUnit and MSpec worked with NUnit (like I really care, seriously)
• We already had lots of existing tests and didn’t want the disjointed feeling of having two ways to do things
• I was already struggling at work getting people to adopt the new things I had already introduced into our environment.

I took what I could out of MSpec and the other Spec Driven Development stuff I got from the community and kind of rolled my own style of doing spec driven development just using MbUnit. I’ve since gathered that there are lots of people doing this.

Recently I had to do a small sample application in a short period of time. It wasn’t for work (i.e. no MbUnit legacy) and I still wanted to do it spec first, so I grabbed the latest MSpec and used that.

I noticed there are several small but appreciated changes that have been made since the last time I used MSpec, namely:

XUnit and (kind of) Gallio Support

To use Gallio/MbUnit or xUnit with MSpec, there’s really nothing special to do – just reference the testing framework you want to use and the adapter assembly.

The adapter assembly is the magic part of MSpec. It helps the unit testing framework build a model of the tests to run. When using MSpec, you’re not putting attributes on things anymore to indicate they are unit tests. The adapter is needed so the unit testing framework knows what to run as tests.

For NUnit and xUnit, there are a bunch of nice extension methods defined for doing systemUnderTest.ShouldXXX() style assertions. There aren’t any for MbUnit, but I made some in my fork of MSpec if you’re interested.

I imagine you could write an adapter for MSTest, as well as some extension methods, but my interest in MSTest-ifying MSpec this ends there.

Once you start using these extension methods, the unit testing framework dependencies kind of melt away:

public class when_pricing_an_item_that_requires_no_sales_tax : with_an_item_to_price
{
    static Money price;

    Because of = () => {

        the_product.is_not_taxed()
                   .when_shipped_to(our_destination);

        price = pricingService.PriceItem(1, the_product, our_destination);
    };

    It prices_as_the_base_price = () =>
        price.ShouldEqual(our_base_price);
}

Where’s the test framework code? Does this use NUnit? MbUnit? The only assertion here is in ShouldEqual, which is one of those extension methods that calls who cares which unit testing framework.

That’s the real lesson here: who cares which unit testing framework you’re using – that decision doesn’t add any value to your product, and doesn’t make this a valid excuse for not using MSpec. If one framework or the other works better with your build process or some tool you are using, just use that framework.

Pending

    public class when_pricing_an_item_that_requires_sales_tax_where_we_are_shipping : with_an_item_to_price
    {
            It includes_the_tax_in_the_price;
            It includes_the_tax_in_the_total_tax;
            It doesnt_include_the_tax_in_the_subtotal;
            It doesnt_include_the_tax_in_the_line_item_total;
    }

I saw Aaron demo this somewhere once, maybe at an #altnetseattle meeting or something, but I didn’t get it at first. I thought it was about going off and writing a bunch of Tests then implementing them. My view that you write one Test, then implement, then another, etc.

The difference is, when doing things Spec first, it’s…well…it’s just different. I think one reason I like one test at a time is that I am testing close to the implementation at that point. Since I am in the process of designing the system while doing TDD, I don’t know what the rest of the design is going to look like till I get there. If I write too many tests, I am speculating about what the design is going to look like.

Specs aren’t so much about the physical design of the system so they don’t change (as much) as the design evolves. If they do, they have good (read: business) reason. It’s not wrong to translate specs into code as part of the same process you are getting them (ex.: talking with a product owner…taking notes in the form of "public class whatever_context { It does_this; It does_that; …}".) That process is unlikely to be as granular as TDD tests, as no business person that is making money wants to hold your hand all day while they spoon feed you one thing at a time.

The output from running the above specs is:

when pricing an item that requires sales tax where we are shipping
>> includes the tax in the price (NOT IMPLEMENTED)
>> the tax in the total tax (NOT IMPLEMENTED)
>> include the tax in the subtotal (NOT IMPLEMENTED)
>> include the tax in the line item total (NOT IMPLEMENTED)

You can go ahead and spec things out ahead of time just saying "It does_whatever" and you’ll get a nice report of what’s to be done.

Behavior

This feature answers a question I’ve had since the first time I saw someone do BDD: What do you do when you want to specify the same behavior for multiple contexts?

[Subject("Calculating sales tax")]
public class when_an_item_is_a_kind_of_food : with_an_invoice_with_one_item
{
    Because of = () => invoice = new Invoice().WithSomeKindOf(Category.Food);
    Behaves_like<NoSalesTaxAdded> no_sales_tax_added;
}

[Subject("Calculating sales tax")]
public class when_an_item_is_a_kind_of_medical_supply : with_an_invoice_with_one_item
{
    Because of = () => invoice = new Invoice().WithSomeKindOf(Category.MedicalSupplies);
    Behaves_like<NoSalesTaxAdded> no_sales_tax_added;
}

[Behaviors]
public class NoSalesTaxAdded
{
    protected static Invoice invoice;

    It has_no_sales_tax_added = () =>
    {
        foreach (var item in invoice.Items)
            invoice.GetPostTaxValueFor(item).ShouldEqual(item.Value);
    };
}

In the samples that come with MSpec, there is an example of two implementations of the same interface, like a TypeFixture in MbUnit.

It seems like, in the applications I work on, I rarely run across a need to use this kind of test, but I do sometimes need RowTest-like tests, or, more often, factory driven tests – like to specify that for a certain set of contexts, there is some behavior. My example above is a lame attempt to illustrate this.

What’s Next

That’s kind of the technical view of things. Hopefully I’ve gotten your attention and you are git clone-ing MSpec in the background right now. I hope to post part 2 of this in a couple of days, with some examples of how I use MSpec in real code.

Things That Went Well

• I was impressed by everyone’s enthusiasm. I was a little worried that we were under-prepared going in, but the enthusiasm and depth of knowledge that the presenters shared was impressive.
• People really liked the Outside-in Testing (Jeff Olson) and TDD sessions (Robin Clowers). These had the most code shown during their presentations, which, I think, says something.
• The facilities were just about right. We were a tiny bit over capacity (technically we were under, but it didn’t feel that way to me.)
• We had the right refreshments and stuff to keep people from getting hungry and distracted. At one point, someone I know asked if we had anything besides pizza, as he has dietary reasons for avoiding it. I felt bad and told him no, making a mental note that we should have some other food available next time, until I realized Anne had prepared Salad and lunch meats. Yay!

To Work on for Next Time

• We tried to cover way to much ground for one day. I think we all knew this going in, but were just in denial or something. Next time: I think we’re going to cover just one topic.
• We hardly got to show any code. I had code that I wanted to show for both the refactoring and patterns talks that I didn’t even get to. I got to show a tiny bit of code in the refactoring talk, but I had a whole series of small refactorings I wanted to do but didn’t. I think we went over in a few of the earlier sessions, it felt right then, but then it compressed the sessions for the rest of the day. The one person that just showed code the whole time, Robin, received props for that. Next time: no slides for me.
• We asked people to bring laptops, then never worked on any code. This was mostly a side effect of the above, I think. Next time: give them the code ahead of time and use the pauses while people catch up with coding tasks to answer off-the-rails questions.
• Some people weren’t into the whole "be interactive" thing. At the start of the workshop we asked everyone to shout out questions as soon as they had them, but some felt this led to derailment. Next time: I think we’ll save space at the end or at pre-determined spots for questions, although I personally feel this leads to people forgetting their questions.
• We (the hosts) didn’t communicate enough before the event and I think it showed. Next time: I think we need to get together on a Saturday a few weeks before the event and make sure we’re all on the same page. I think this is one area where I personally did a pretty poor job, kind of assuming everyone was "directionally correct" and just kind of knew what to do. For the most part this was true, but I think this will be something we improve upon.
• Using git and markdown was great for the geekier amongst us, but proved a burden for some of the presenters and the attendees. Next time: git for us to share the code, zip files (skydrive?) for everything else and for code for the attendees to download.

In summary, I think the loudest message was: more code. I am in total agreement and I usually don’t like to use any slides at all if I can help it, but somehow got the wrong headed idea that I needed to have something to look at while I did the talking, intro-part of my sessions.

I also tried rehearsing more than usual for this and it turned out to be a complete waste of time. The actual session went wayyyy slower than then I rehearsed. I must be doing it wrong. // TODO: Imagine Arun
asking questions while I am rehearsing.

It sounded like the majority of the attendees would like to come back for another session like this, more focused on one topic. The organizers are going to hold a skype retrospective sometime in the next few days and figure out what we want to do next.

I’d like to give mass props to the people that made this happen: Justin Bozonier, Robin Clowers, Bobby Johnson, Jeff Olson, Trevor Rotzien, and Anne Wax. Together we are helping ALT.NET grow from a small fringe group into something that’s doing real work and making things better than when we got here.

UPDATE: We actually held the retrospective last night. We’re planning another event soon, possibly in more locations, something more focused. Keep your eyes peeled.

I am hoping this will raise the bar a little bit and get more people walking the walk. My view has always been that we all have to work together, so better to get everyone up to speed on what’s working and what’s not, and for as many people to be passionate and excited about the work they are doing as possible.

Anyway, here’s the official announcement:

You’re at work and you catch yourself writing another 100 line method that you can’t test and really can’t even understand. You scour the internet for ideas but there are so many ideas. Some say don’t test, others says don’t test anything, still others say test every keystroke! You just let your head drop to your desk with a solid thud. You think to yourself, “Is this really the best I can do?”

The Olympia Software Craftsmanship Workshop is one day workshop, developed with the intention of increasing the level of awareness of practices and skills that can improve our software.

Any developer interested in improving and learning new skills is welcome. If you can bring a laptop, please do. We will provide the software you need. If you can’t bring a laptop, don’t worry, you can pair up with someone who has one.

*************************************************************************

What: Olympia Software Craftsmanship Workshop

Where: Olympia Center, 222 Columbia St NW, Olympia, WA 98501

When: Saturday June 6, 2009.  10 am to 4 pm

How much does it cost? $25.00 to cover the cost of the facility and lunch.

How do I sign up? Go to www.olympiasoftwarecraftsmanship.org

The workshop is hosted by members of the South Sound.NET users group and Alt.Net Seattle who want to help others build better software.

For more information: http://github.com/altnetseattle/olympia_software_craftsmanship_workshop/tree/master

Or contact Bobby Johnson at bobby.johnson@gmail.com

I hope to see some of you there!

Disclaimer: I am far from an expert on retrospectives (for that, see Diana Larsen). What I know about retrospectives has been gleaned from listening to other people and trying a few things. I am writing this more to start a conversation than to preach my interpretation of what makes a good retrospective.

At Russell, for the first couple of retrospectives we did, I think it felt too “touchy feely” for most of the group and they had trouble getting started saying what they needed to. Once they got going, it turned a little dark and we started focusing on negatives, especially unsolvable ones. By the end, we were wondering what was supposed to happen next. This wasn’t how the people at the conference I went to did it. What was going wrong?

For one thing, our teams are too small (3-5 people) to include much of the ceremony around retrospectives. Eventually, we ended up doing a simpler kind of retrospective:

1. Get a room.
2. We make a list, two columns, good and bad things about the iteration.
3. Quickly, roughly size the things.
4. Pick 3
5. Figure out how we’re going to address them

We usually only end up with technical people in the retrospective. For whatever reason, what’s expected of product owners generally remains static across iterations, so there isn’t too much for them to improve on. Depends on the product owner.

Making the list takes up the biggest part of the meeting, from 10-30 minutes for us. Towards the end, it’s usually one person, reaching way deep into things that aren’t going to get addressed anyway. It’s good to cut this off, but my feeling is you need to let it go on for a little bit, so everyone feels they had a chance to say what they needed to.

As I mentioned earlier, sometimes this turns into an…umm…”complaint”-fest. It’s important to cut this off. We’re listing things, not trying to solve anything or blame anyone. We just want to build a mini-backlog of potential things to address, not address them. Addressing them before we know they are the next most important things is waste.

The sizing part is quick and easy. Just Small/Medium/Large, 1/2/3, A/B/C, whatever. The main thing is to call out those big things that you probably won’t be able to address and to get an idea of your velocity in getting these things done.

Picking 3 is the magic part. The three isn’t magical, just a good starting number. Once you’ve gotten and idea of how many “retro points” your team can handle in an iteration, you can use that instead, if you want. Here’s where we have to be honest about what we can get done, in addition to all our other work, as part of the next iteration. If we pick a hard thing, are we really going to have time to address two more little things? Are these little things over here really valuable enough to spend time on? The selection criteria is a function of value and cost, so there is no sense going into problem solving mode until you have those two pieces of information and can select the right amount of stuff to work on.

Once you’ve picked out the things you want to tackle, figuring out how to do it is usually pretty easy. Just don’t let anyone sneak their favorite unaddressed item into the problem solving phase. Focus on just the things you know you’re going to get done.

Finally, everyone agrees that we’re going to address the things we picked. At the end of the iteration, we’ll measure the teams performance against the goals they picked, so it’s important we all agree.

If this sounds a lot like the way we do features and stories in an agile process, yeah, that’s kind of how I think about this. It’s how we address things in our process that we can’t/don’t want to, for whatever reason, introduce into the main backlog for the project. Process improvement is overhead, and the things we come up with in our retrospectives are our backlog for overhead. These things don’t have first order business value, but second, or third order.

Some Lean teams have sworn off retrospectives, perceiving them as waste. Like anything else, retrospectives aren’t going to add value for every team. For my team, retrospectives are quick, easy, and valuable when we stick to the important parts.

For those who don’t know me, I am a .NET developer at an investment company in Tacoma, WA. I participate in the Seattle ALT.NET and try to go to local user groups, code camps, and other events, when I get a chance…which hasn’t been as often as I’d like this past year with a new baby and a 6 year old!

Anyway, thanks to the Elegant Code crew for inviting me. I am looking forward to starting some good conversations here!