Fellow Seattle ALT.NETter Aaron Jensen and his friends at Eleutian released a really interesting library of functionality several months ago called “Machine.” There are several things in here I can use every day. Not all of it is perfect, but it’s very innovative, clean, and easy to work with.
Today, I want to talk about Machine.Specifications, or MSpec as I will refer to it going forward. If you haven’t read Aaron’s introduction post, read it now, then come back and read this.
I am still learning BDD but I am already enjoying some benefits of it in my tests. For the most part, I have just been adopting BDD style naming of my fixtures/tests (or rather, contexts/specifications), using my existing testing framework (mbunit), and using really detailed versions of the stories our Product Owners come up with. I get two main benefits:
- Product Owners would know what a test was covering.
- My tests are coupled to the user stories, not the code.
The advantages are offset by:
- Product Owners don’t look at the code. It’s a psychological barrier, but it’s there.
- I am still new to BDD so keep running into things that I find hard to express in BDD terms.
One thing almost all BDD frameworks offer that hits one of those bullets is functionality to format a bullet point list of the specs that are implemented from tests following a naming convention. That alone is enough reason for me to try some of these frameworks.
Concept: MTEGOTAG (pronounced “Em Teg-O-Tag”): Mean Time to (Product Owner) Eyes Glazing Over Thinking About Golf. When I write my specs in c#, this number is very low, approaching zero. I can keep a Product Owners interest for 10, maybe 20 seconds if I am showing specs in c#. The number gets even lower for each repeated application per session.
So that’s kind of my motivation. I recently had some time to sit down and actually do real work in mspec, my next post will be about the results.
P.S.: If you are in the seattle area and don’t already know this, a bunch of us are meeting to talk about BDD this Thursday.