A few weeks ago I wrote a comment on Scott Bellware's blog that, like a lot of the TDD crowd, I was becoming enamored with BDD.  I think I probably perplexed Scott a bit until he realized that I was leaving out the TDD component which I guess in the truest sense is of the methodology can't really be left out.

Regardless, some of the discussions on this stuff is finally starting to sink in and I can see what I could be testing.  Now before anyone rejoices that you converted the Dev Theologian to TDD; I'm still not doing TDD (nor will what I end up doing be called TDD).  I just finally figured out how to best exploit the Unit testing tools to give me what I've wanted for some time.

You see as a Git 'R Done (GRD) programmer, I care a lot less about having tests for everything.  What I want is to test the "low lying fruit."  I've been struggling for a couple years on how to determine what that is.  I have stated again and again, TDD doesn't provide me enough ROI for me to do it.

So first let me tell you briefly of my journey over the last several months....

The Journey
It all started a couple months ago.  I was going through my yearly "maybe I should do TDD" phase (BTW, this replaced my yearly "I should learn c++" phase), and was reading some stuff on xUnit testing frameworks.  I happen to read Phil Haack's blog and noticed that he had posted some stuff on MBUnit.

If you are a TDDer you are probably well aware of MBUnit.  If not then let me tell you, MBUnit has a number of niceties that make it easier to test certain scenarios.  The one that threw me over the top was Phil's post on the RowTest which is a way to create a parameterized test and provide tabular data for that test (Ok I forget exactly which post it was... it might have been this one as well... or maybe it was this one).

Anyway I now had an Unit Testing framework that didn't look like I was going to be working really hard to use it... now I needed to solve my other problem.  What should I test?  What's the low lying fruit and more importantly can I test something that will benefit me today and tomorrow (in other words I want a notable ROI).

Enter BDD
The BDD guys are really dealing the big questions about TDD.  Let me quote from the NSpec homepage:
"In essence, what Dave is saying is that the test oriented nomenclature gives us too many reasons not to write tests, especially when the pressure is on."

Actually as I re-read the NSpec homepage, Scott B's comments about BDD being coupled to TDD don't seem entirely true.  Especially the comments about 1:1 testing.  The main idea with BDD is that you take scenarios or stories (to use Agile terminology) and create tests out of these scenarios.  In the UML world these would be with use cases (well sort of) that tests get tied to.

Anyway, as I looked at this, I began to see how and what to test at least from a very simplistic manner.  Test the spec and the scenarios that fall out of it; so, don't worry about testing everything.   I have been told by a TDDer a few years ago that one should always test every class and here are a few examples of what to test: class instantiation, test for null against an unistantiated class, and , serialization  (if you need this.. since he was a SOA guy he felt you always needed it).  I won't comment on any of these these examples except to say "ROI??"  It costs almost nothing to do these tests but am I gaining anything by just having tests for the sake of tests?

A GRD Testing Methodology??
So I have been thinking about BDD and how it can be used by a TAD (Test After Development) developer.  What I want is to be able to test something and know that the client is going to say "hey that pretty much does what I expect it should." Using a BDD like approach to unit testing will give me that.  I can test the spec based on my understanding.  If I use the scripts that BDD provides I can know that I pretty much understand the spec.  With this info it should be easy to come up with tests that take care of my low lying fruit.

I would love to layout a full blown GRD Testing methodology.  Unfortunately I am blazing away at new ground for myself (and honestly I'm not that smart).  I've made quite a bit of use of MBUnit in the last couple weeks, and am getting the hang of it (it's quickly becoming a tool in my debugging arsenal).  I'll try to put up some posts as I gain experience so we can explore what this means to a GRD programmer (but again, I'm not that smart).

Don't worry I'm not going all ALT.NET on you.  Nor am I going all TDD on you either.  So if you hate my methodology ideas, you probably still will.  If you like my ideas then you probably will see some logic in where I'm going.

Do yourself a favor, go read up on BDD.  You'll find some stuff there that is thoroughly useful no matter what camp you fall into.