Classifying BDD Tools (Unit-Test-Driven vs. Acceptance Test Driven) and a bit of BDD historyBDD (Behavior Driven Developement) seems to gain momentum lately.
BDD is hard to grasp, because it is more than a development methodology (unlike TDD) and there are currently very different ideas what it really means. To make matters worse there are a lot of BDD tools around that pursue quite different concepts.
In this post I try to classify two main categories among those tools.
Important for the understanding is that BDD can be practiced at different levels. At the code/unit level and at the feature level. In both cases it is a good practice to use examples to specify the behavior of the units resp. features. However in both cases we have different stakeholders and intents with the BDD process.
Both approaches to BDD are not exclusive, they can be combined.
(see also "BDD for Acceptance Tests vs. BDD for Unit Tests (or: ATDD vs. TDD)" on the SpecFlow mailing list)
Currently I would differentiate two flavors of BDD tools:
- Tools with a business readable output
- Tools with a business readable input
Tools from the second category (business readable input) try to widen the focus of the BDD process by enabling more involvement by all other stakeholders: customers, business analysts, testers maybe even operations.
This involvement is possible upfront, meaning before the developers have done their work. This business readable input is an artifact commonly owned by all stakeholders. By having a commonly owned artifact, the process tries to ensure that all involved stakeholders build up a shared understanding which is crucial for successfully software projects (for more information I suggest reading Bridging the Communication Gap by Gojko Adzic).
Because this shared understanding is input (as opposed to output) and business readable, the process can even be taken further and make the artifact business writable. If this is achieved successfully then we have done a big step towards executable specifications.
In practice we often see tools of the first category (business readable input) used as a replacement/extension for TDD at a unit-testing level.
In this case the behavior of the unit under development is focused by trying to specify this behavior upfront in a less technical way. However this is usually not interesting for other stakeholders than developers, because the technical units under development are usually too fine grained and have no meaning to non technical persons. Also technical units are the primary focus of developers and they are the main stakeholders (think of testability, separation of concern, maintainability ...), other stakeholders should not be too involved here. So this is mainly a tool for developers and allows in some cases the mapping of technical units to overlying features.
The second kind of tools aim clearly at Acceptance Testing and Acceptance Test Driven Development. Here system features are clearly focused. Features are usually more coarse grained than the behaviors of single technical units. Features should always be understood and driven by business requirements.
It is certainly possible to write acceptance tests with the first category of tools, but the driving aspect (as in Acceptance Test Driven Developement) is certainly harder to achieve and less supported by these kind of tools.
Easyb is a Groovy based tool of the first category. The following example (from this post) shows how behavior is specified at at unit-level (class-level):
Executing the above story gives you the follwowing readable report:
(of course easyb can also generate a fancy html report)
Cucumber is a tool of the second category. The following example from cuke4duke shows how an executable feature is specified:
(notice the error in the second scenario!)
When executing this example (using cuke4duke) the whole EJB stack is exercised, including database-access. The result is the following report:
(of course Cucumber can generate a lot of different outputs)
History (as I could reconstruct it):
Tools from the first category evolved from TDD. Dan North introduced BDD in 2002, see his introductory blog post.
JBehave was one of the first BDD tools, at this point clearly part of the first of the above categories.
Then the BDD movement was mainly driven by the Ruby/Rails community. RBehave was introduced and then merged into RSpec as RSpec Story Runner.
RSpec then was as a tool that could satisfy both of the above catgories
RSpec StoryRunner was then dropped and Cucumber was created. Cucumber coined the current flavor of BDD tools with plain-text specifications. Cucumber also is aiming at extending its reach beyond Ruby/Rails (see cuke4duke, cuke4Nuke, gherkin).
Other first-generation tools then adapted and also support plain-text specifications (JBehave2, NBehave).
Beside all those explicit BDD tools there is FIT/FitNesse. FIT was also invented in 2002 by Ward Cunningham. Its goal was enabling collaboration and communication through automated accepatance testing. FitNesse took up the basics of FIT and provided an intuitive, wiki-based frontend/IDE.
While FIT seems to have practically died, FitNesse is still thriving. FitNesse also recently added Parameterized Scenario Tables and there is GivWenZen. This makes it possible to use the plain-text GWT (Given-When-Then) syntax, that was made popular by the plain-text BDD tools.
I will list a more complete overview of BDD tools for the Java and .Net platforms in later posts.