There are two basic design methodologies in the software development world: top down and bottom up. In bottom up, the goal is to piece functionality together to “build up” to the desired result. In top down, the goal is to break the problem into smaller and smaller parts until you have implementable pieces.
Both have strengths, and by correlation, both have weaknesses. Analysis and design phases in pre-agile days were almost ubiquitously top down. They would take business requirements, translate them into functional requirements, then break those down and assign the constituent pieces to developers. As the code was implemented, weaknesses in the design would be exposed, and feedback would go back up to the level of functional requirements—or, in really bad cases, to business requirements—and a mini-iteration would take place to resolve the problems.
When agile came along, this was all too slow a process. To be sure, it was (and is) still used and has produced some of the world’s best software, but an agile team can’t sit idle waiting for a long process of analysis. Kan-Ban and similar tools/processes were introduced to address this issue, making the pieces being designed smaller and thus speeding the process somewhat. But smaller pieces implies bottom up to some extent, and the waters got a bit muddied.
Test driven development (TDD) was designed to make sure the code written met the technical requirement by writing a test for the expected result before the actual code. This was one of the most fruitful things to go into/come out of agile development. While it has flaws—the most significant being the human factor—it does make more thought go into code being written and more rigor come out of code produced. The act of writing the test makes the developer think of ways to solve the problem that satisfy the test. But the source of those requirements still needed to come from some form of process.
Enter behavior driven development (BDD). It’s not really development, though the name is catchy. It would be better named behavioral design for TDD, but that’s a mouthful.
In short, the idea is that business owners and analysts speak in terms of the needs of a given role, while developers speak in terms of functionality or the results of a given test set. This creates a gap that causes misunderstandings. The goal of BDD is to get everyone speaking the same language. It tries to extend the spirit of TDD up the design/analysis stack—”shift it left,” in today’s parlance—so that the tests being developed are a hierarchy stretching from acceptance testing down to unit testing, and everyone is speaking the same language.
En vogue today for the language is Gherkin, a simple requirement specification language that writes requirements and test criteria with (relatively) strictly defined sentences. I say “relatively” because, the language is a bit loose from a unit test perspective. But from role-based specification, it is locking down options to make the environment and test cases clear.
I actually got to thinking about all of this while considering SmartBear’s recent acquisition of HipTest. SmartBear has made an investment in making its tools BDD-compatible, and HipTest is largely a BDD platform. The combination of the two should see some movement in the BDD space that will be interesting. I spoke briefly with SmartBear about the acquisition, and it seems the company really is merging the strengths of the two organizations, so it is worth watching over the next few months.
Thus far, the benefits of BDD that jump out are the ability for everyone to talk about an element of the product in common terminology, while the developer can think “down” to the code required to meet the requirement and the business analyst (or owner) can think “up” to determine how to market this cool new feature.
Tools are out there to generate TDD test classes/cases for a variety of languages—notably from my stable, Python and Java. This might be a huge step in the right direction also. Just the other day I was having a bit of a lighthearted conversation with a peer and said, “Get to the point where you can auto-generate tests at build time for us, so IT managers aren’t stuck deciding which lines of code are/aren’t worth maintaining test code for, and then we’ll talk.” Tools and frameworks such as Cucumber and JBehave actually take steps in that direction, though their approaches are different.
We are not currently using BDD on our in-lab test application (Android/web clients, Spring API server) at work, but will have to consider it moving forward as another bit of DevOps tooling and practice we can experiment with. The tools are there, and the process bridges that sticky part of analysis and design where top down meets functional.
After all, the end goal is giving users what they need. If BDD helps make that process smooth and faster, it is a fit for any DevOps environment.
