Hi there. I am Petyo, and I am into software. Recently, ruby and rails seem to be the weapon of choice. And them rails folks love to TAFT. A while ago, trying to blend into that brave community of ‘radicals’, I decided to give webrat with selenium for unit testing, in order to mitigate the constant slippery of client-side errors the project was experiencing.
As usually, one thing leads to another. Soon cucumber was in the game, and, before you know it, purchased the beta of the rspec book, reading about the strange and sometimes awkward syntax of my new tools.
From a programmer’s perspective it was not all that different than the xUnit frameworks I knew. Sure, things were called differently, I was “shoulding” and not asserting, and the MVC concerns were split in a slightly different way. A matter of taste, I was thinking, let’s try. Many people were stating the same. I was not really paying attention to the required native language descriptions, considering them redundant at best.
Meanwhile, I was rereding the book, (more like a reference), occasionally switching to The art of agile development . When it hit me. As usually, I was doing it wrong. Well, not wrong really, but rather missing the point. I was doing TDD with the BDD tools.
As usually, wikipedia nails it:
Behavior Driven Development (or BDD) is an Agile software development technique that encourages collaboration between developers, QA and non-technical or business participants in a software project. It was originally conceived in 2003 by Dan North as a response to Test Driven Development, and has evolved over the last few years.
BDD, while carrying all the benefits of TDD has certain (less than) subtle differences. BDD is far more aligned with the Agile values, and leverages the concept of testing to force developers in actually communicating with them customers. With TDD, you aim at verifying that your code actually works. With BDD, you are communicating with the rest of the team, providing human readable artifacts, which reveal the logic you have implemented.
It took me a while to figure out this. BDD is not about the tools, it is about the process. The sole usage of rspec, cucumber or any other BDD framework out there does not make you behavior driven. It is all about the communication, which the agile evangelists love to brag about. And yes, it is a bold attempt to resolve one of the most complex problems in our industry – project failures.
Hold your horses, and read below first. Let’s figure if you really need it. Remember: To go for behaviour driven development model, you should first qualify for the test-driven one. But is it so? And why is not TDD practically in every software shop out there? Why don’t we study it in the universities?
The often overlooked fact is that many companies and teams don’t care about stability and lack of bugs. In many cases, rightfully so, since this is not going to make the software successful. We all know examples where buggy, slow software achieves mass appeal because of good marketing and sales, or because of brilliant idea. Or just because of pure luck.
This is actually a good moment to stop reading and ask yourself if the above is not applicable to what you do? Maybe you are a bolt in an enterprise product, where the sales decisions are made by exectutives puffing fat cigars driven by commission rate contracts. Maybe your main revenue comes support and consulting (relying on a buggy product), and ‘priority bug fixing’. If this is so, then you can safely ignore this article.
Adopting BDD is even harder. Because it faces all of the problems its predecessor along with the obstacles that prevent Agile from being achieving mass appeal.
Well, a lot. Actually, BDD makes sense only in Agile environment. Otherwise you’re just talking to yourself (which is acceptable in another environments).
Many people perceive Agile as yet another “methodology”. Nothing can be further from the truth, actually. Agile is just a term that wraps a set of values, that the team shares. Well, at least should share. If your team shares them, the practices such as XP, Scrum and so on come naturally, because they are just tools for reaching what matters for the team. Without Agile, Scrum is just one huge masquarade, where people pretend to listen to each others yada-yadas.
If I had a spare wall, I would print this in bold:
The Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the things on the right, we value the things on the left more.
A hidden message that has long evaded me here – the first line in the manifesto is a value itself. A person with an “Agile” mindset proactively searches for better ways of developing software.
Unfortunately, the Agile manifesto has a problem with many software producers’ personal values and reasons for dealing with software. Try it for yourself – answer honestly what best describes your motivation for doing software. A few hints for free:
- I am a sociopath and I hate dealing with people. Being a programmer gives me the freedom not to interact with them nasty human beings on a daily basis;
- I am all for the money, and there is nothing that can put more cash on the table;
- I wanna be a famous artist/rockstar, but I failed at playing the guitar;
- It just happened, while I was wondering what to do with my life;
- I see myself as a smart person and enjoy resolving complex problems;
Are you offended? Maybe some of the above applies to you? Well, none of the above is that bad in fact. Unfortunately, if they are the reasons for you doing software, then your personal values are in a direct conflict with the agile mindset where working software, collaborating with customers and interacting with the individuals should be the main motivation.
Back to BDD, the point I am trying to make here is that any attempts to adopt it without first making sure that the agile mindset is clearly present in your team does not make much sense. Sure, you can write specs, and elaborate cucumber features – but this won’t be more than a fancier TDD (or, at the best case, a single person BDD – not that bad as an excercise!). BDD really shines when it comes to team collaboration efforts.
By forcing you to speak more of their language, and by keeping you focused on resolving the problems that matter instead of floating away in activies that have no business value for the project.
Unfortunately, most of the time the technical aspect of bringing the natural language definitions to the rest of the team is left as an excercise to the reader. However, I would like to give you a suggestion – use Continuous Integration. You do have one, right? It will constantly update and visualise the business cases you’re working on, the ones that are being resolved, what is pending, what is broken, and what is in progress – either by emails or by generated web reports. Your latest specs will be at the top, and the managers will be able to receive a good answer to the simple questions – what are you doing currently? How’s it going?
Perfectly valid point, especially valid for non-agile teams. Unfortunately there are two, sometimes overlapping reasons for that.
First of all, them business people are too busy. Oh yes, they are. But if they are too busy to pay attention to the project they payed money for, then it is obviously a project that should not have been started in the first place. You need a domain expert to verify your work, and you need a stakeholder to be up-to date and to make decisions on priorities and release schedule.
Second problem is that Specs descriptions often do not make any sense to non-developer. Guess what? You are the one that provided sloppy natural language descriptions. And I do feel your pain at this point, because us developers historically suck badly at explaining our actions. You should give up on this though. Read the output of the spec results with the rest of the team. Ask for feedback frequently; what makes sense? Which explanation is too vague? Aren’t the specs for some internal code parts too “technical”? This may be considered a clear sign that your application design differs from the domain.
To wrap it up, “The Revolution Will Not Be Televised”. A BDD is just a practice that makes sense in the right environment. Without it, it is just a nice test-first methodology that the developers may practice as an excercise. Remember that the agile environment relies heavily on each individual personal virtues, and true agile teams are rare and hard to find and build. And forcing agile is not known to work.