Story about stories or “how we started to do BDD”

My colleagues started to work on the project where the team was split into 2 subteams located on different places. The problem was that our part (development) was dependent on the second part (DBAs, business). The project started and we found there is a problem with the cooperation – specification was unclear, DBAs did a stored procedures but didnt test the correctnes of them, developers spent quite much time analyzing why the stored procedure doesnt work, they tried to change the stored procedures with informing DBAs what was changed, etc. At the end of the day the process was time-consuming.

BDD is comming.
When the project started to be in red numbers, my boss asked me to find a solution for it as I’m lead developer in our company. I knew that this is right time to come with a new approach – I found BDD. I started with idea that we need to be independet from DBAs and we should be the masters who will instruct them how to write the st.procedures. The project was developed using “developing against interfaces” approach in conjuction with Spring.NET, Dependecy Injection, etc. I came with idea that we create a mock data access layer (DAL) which returns fake data just to do our development. It was also necessary to somehow specify the behaviour of DAL – at the end the stored procedures.  Did you see the word “behaviour”?  So I  started to do TDD. As I had a practice with it, I wanted something which describes the dehavior of the system and the description of the test will not stay in the code only. Fortunatelly, I found NBehave.  

I must say as the developers are lazy, it’s very hard to ask them to start to think in new way. First write the test, then the code and then do refactoring. Even now, after 2 months of BDD some skilled member of the team has problems with it. Anyway I did a sample on audit message logging part of the system. I showed it to the developers and we started. After few weeks we started to ask DBAs to create the procedures which have the behaviour described in the specification which are coded and tested. When DBAs create the procedure, we employ it into the DAL,  change the setting of Spring.NET factory and test it. It works perfectly because we dont loose the time analyzing the procedures, every changes (even system settings) in DB are tested. We use NBehave in conjuction with Spring.NET and Rhino.Mock.

Why to use BDD?  What is the added value?
I must say it’s very big.
1) The developer thinks about the code before coding it. First, it takes a time but at the end of the day, he is sure the code is under tests and wokring fine.
2) Description of the test = behaviour of the code. It’s the most critical part, I think. The test are described using business/natural readable form. Via TDD only the developer knwos what the test is doing. With BDD the business people(BP) or project leader(PL) can check what the test is really testing (or at least should). The PL or BP can checks what is the current situation with the project.
3) When writing BDD specs in the code BDD forces the developers (wo are very lazy) to write the descriptions of the tests in the understandable format. It’s visible to the PL so they needs to be quite responsible to do it.
4)BDD is about description of the application behaviour. The best person to write them are business people. But it’s very hard to ask them to do it. We have our testers/analysts who write the testing scenarions (do you see?) Testers need to understand the system in order to test it well. So I think the best way is to ask testers/analysts to write the stories with testing scenarios for application parts. For some specific parts developers can do it, too. 

BDD for UI?
BDD goes in hand with MVP pattern – model view presenter. It enables us to describe also the behaiour of the screens.

Summary
NBehave is great tool to use for BDD and describe the  system. The descrition stays in the code, it’s still up to date and under teh tests, it doesnt stay in word document, it’s still usefull to track the status of the project.

What is missing?
1)I miss the conjuction with CruiseControl.NET very much. This automated build process and intergration is the access point for PLs and business people to check the status of the project and they should see it automatically with each build.
2)I miss support for Exceptions. I mean a code like:

story.WithScenario(“scenario”).Given(“precondition”).ExpectException(“business exception”).When(“do an action”);

In the next my blog entries I’ll write about examples how do we use Spring.NET, Rhino.Mock, NUnit in conjuction with NBehave.

Peace!
F