Provable value of BDD (or YABDDIP – Yet Another BDD Intro Post)

As I am a semi-novice TDD developer (although the following remarks are more intended for your classical Unit testing developer, simply because I am talking about testing, not designing which is the point of TDD. And also I am considering myself as a semi-novice because I’ve actually been convinced with the idea for so long, even done some projects, but I am still having problems enforcing it in my company) I’ve always found myself troubled by a rather simple question:


How can I know that a given functionality (or a piece of code) is tested? Or how do I know that a developer working with me in a team has tested it and/or written it completely?

I mean… I can write 5 tests for a given functionality, my colleague can write only 1 and a TDD expert can write 20.

We will all be convinced that we have done a good job testing that piece of code – I will test it partially, TDD expert will test it probably 90% and my colleague will only smoke test it.

Without looking in details at the tests, how would I know who of us made a good job of it?

And even better… did any of us?

To be able to answer that… we would need to set up a baseline – or even better, what are we measuring against?

If you think… the code did not brake… well, in all 1-20 tests of all three of us it didn’t?!?
If you think… it does what it needs to… how do you know that it does? Even if TDD expert did write 20 tests, maybe he missed a couple of important use cases of a given code fragment.

Note that this concern is even magnified with TDD – where you try to write as little code as possible to satisfy a given functionality – this is one of the core ideas of TDD – and one of the areas where I see it really excel – not writing un-needed code and tests.

I can write a code to satisfy 90% of the logic – and that part will be 70% tested – how do I know these numbers? Well I don’t. I can only guess – as much as anyone – what is important that our tests cover our imaginary design – and it is imaginary – because at a given fragment of time – we only think that our functionality is done, or that our design fits correctly into the bigger picture – we can think it is, we can even have some indications and be reasonably sure it is – but is it really?

Or a better question – when a developer comes to us and says, I’ve developed it – it’s tested and working – I’ve written 50 tests to cover the code – is that enough? Is the functionality done?

What I am missing in both cases (and have been when thinking about these ideas) is the acceptance criteria – plain and simple – I want to be 100% sure that if I wrote 5 tests – that those tests mattered, and that they test what they need to. I don’t want to rely on my (or my colleagues) experience and proficiency at testing – nor design for that matter.

(I sound harsh… sorry! I am not putting names or blames on anyone – nor do I miss confidence in my dev. team - but we are all professionals – and if I want to be professional about what I do – I must be exact and correct – and more important – I cannot go check every bit of my colleague’s code and tests against the client’s requirements)

Now… before going further… please don’t think that I see the following (BDD) as a silver bullet to answer the asked question – simply a technique to improve my teams scoring on the subject.

So, what would I want – I would want something measureable - for example, with a given task, a check list of things that a given piece of code must do or rules it must conform to.

That is great – but the problem is that it’s still not executable, and thus must be confirmed manually – so really yuck!

Here is where I see that Behavior Driven Development comes into play.

If we start with the behavior – and work towards the functionalities – and that behavior is pre-defined in the form of scenarios of a given story – we can have pretty solid acceptance criteria for our team’s developers to follow.

Before moving on, take a look at these great links:

http://dannorth.net/whats-in-a-story

http://persistall.com/archive/2007/11/02/bdd-with-just-nunit—a-first-attempt.aspx

If I see it through the eyes of BDD – my talk to my fellow developer might be:

When showing the list of customers, note that that list must be:

- Should return an appropriate message if no customers are found in the database
- If shown should be paged with 10 records at a time
- Should show the customers ordered by their first name
- Should have options to edit or delete a customer

So I am talking about the context:

“…When showing the list of customers…”

And I am giving the acceptance criteria to my fellow developer:

- Should return an appropriate message if no customers are found in the database
- If shown should be paged with 10 records at a time
- Should show the customers ordered by their first name
- Should have options to edit or delete a customer

That developer can now easily make a Fixture:

When_showing_the_list_of_customers

With the tests:

Should_return_an_appropriate_message_if_no_customers_are_found_in_the_database
If_shown_should_be_paged_with_10_records_at_a_time
Should_show_the_customers_ordered_by_their_first_name
Should_have_options_to_edit_or_delete_a_customer

This is a lot more un-ambiguous from the start! I see advantages from all 4 points of view:

Team Leader – I am happy to finally be able to communicate to both developer and the client the acceptance criteria of a given functionality and to hold and be held accountable by it (remember that being a professional part?)

Developer – I am happy to know 100% what I need to do my job correctly – there should be no misunderstandings or “I think…”, “But, You said…” troubles

Client – I am happy with the level of professionalism at which the team communicating with me. I am can easily add to the list things that I see missing (it is so simple). I get more predictability and accountability for my money

Manager – I get more predictability (and managers really dig this oneJ) for my (clients?) money

Sounds good doesn’t it?

To me too

And all of this while practicing the great ideas of TDD and Unit Testing!

Disclaimer again: It is not a silver bullet! You will hit a wall with C# limitations, with questions you will ask yourself (see Brian Donahue’s post above for some self-questions) – but it is a huge step up and in the right direction!


What do you think?