[Sorry it’s been a long day and this is a rather stream of consciousness post... ]
If you have followed my blogging for any length of time you’ve seen me jousting (sometimes shouting) with the Agile crowd of Testing First. Actually I think my complaints have been more in line with some of the nuances of their architectural advice. We won’t get into that arena right now though.
[Digging out my best Katy Perry voice]
So, I tried BDD and I liked it
Yep, you heard me right. Not only that by I fired up moq and mocked/isolated/faked/doubled (pick a word for "fake version of an object") in one of my tests. And, oh yeah, I did it all first. Since you are all in shock, let me throw one more thing out there. I used SpecUnit.Net to do this all. You may not know what the big deal in that is. SpecUnit.Net was written by none other than Scott Bellware (he would be the guy I spent a lot of time shouting at in my blog).
Ok, so now that all the shock has died down, you may be wondering how this all happened. Again, if you’ve been following along, you would see that I have had a serious fascination with BDD. In fact last month I went to a CodeCamp and attended a session by Sean Chambers (session content is mostly presented in this post). It really hit some chords, and I vowed to try it the next easy opportunity I could.
So yesterday after Christmas break, my boss tells me, "I’m changing all your priorities. Here’s your new priority/project." I was then given a spec document with some rules for how the new feature would work (lot’s of use cases). On the spot I saw this as a perfect BDD opportunity. I built a test project/solution, added in all our support DLL projects and began to write Contexts, Observations, and Concerns (all BDD terms). I let the tests lead me and today I needed to test one final thing and realized that I should isolate things so I used moq which caused me to make a few API changes. All in all it was an excellent experience. I ended up with 2 concerns, 46 observations/tests, and 2 Contexts. I used Scott B’s reporting tool and got a couple warnings about my tests that implied that I might have a context hiding there which is probably true.
For the unenlightened, let me try to (poorly) define the terms. Context roughly equates to your setup code for each test; it’s a little more involved than that, but essentially you should have a context where all this runs. Observation is pretty much a test (although they should correlate to your "rules" from the spec document). A Concern is like a way to categorize all this stuff together, it can go beyond a single test class, but the idea is that you probably have say an "Order System"; that would be a concern. The Observations might be "do not ship the product if the customer hasn’t paid (there would be a context of "Customer has Paid" and "Customer has not paid"). Again this is all really , really rough... go to a real BDD gurus site.
So does that mean you’d switched ships, Jay?
Not exactly. I mean at one level it means that I will be developing more code this way whenever I can. I think I’ll always stay my own pragmatic self (which is not to say that Agile guys aren’t pragmatic... I’ve met my share of them now and they aren’t who I’ve been beat up by). I will be adopting some of their practices where it makes sense. I finally got a testing success so who knows where I’m heading.
Advice for the Agile Evangelist
I think you guys need to abandon TDD as a starting point. BDD makes more sense to the average corporate developer. Every project has specs (no matter what you call them). Writing tests using those specs first really makes sense. It’s why I was very interested in this methodology the first time I read about it. The methodology also answers all those newbie questions immediately. Stuff like
- Do I gotta test first? [yep, if you want to make sure your code passes the spec’s rules... it’ll also help you see the edge cases that should have questions raised with the customer/client/business owner]
- What do I test? [You test the spec. First and foremost... I know this skirts into dangerous waters here... but convincing people to test something will lead to more testing if it proves to make code more stable, etc.]
I found it easy to get into the "red, green, refactor" rhythm, and even caught some minor problems along the way. I imagine a newbie would have the same result. Now from here you have a platform to talk about improving someone’s ability to test.
The end-result for my code
Well, time will tell, but my back-end API changes don’t allow the UI to violate any of the rules. It was the type of spec where I have some fields that cannot be changed which has some additional effects on other objects. When a field is read only it CAN’T be written to. The individual properties enforce this functionality. Additionally the other rules were easy to implement. And all this happens outside of the Data Layer and not in the UI Layer (thank heavens!) I know none of this is rocket science, but there are a really large number of places in the UI where these things can be violated (I needed to make sure the Business Objects took care of business).
Print | posted on Tuesday, January 06, 2009 7:36 PM