BDD Coming to a tool near you
Stories Columns Opinions Resources
Sun extends Groovy, PHP support to NetBeans
Version 6.5 of the IDE will see complete support for those two languages along with comple...
|
Sun reorganizes its software production infrastructure
Facing economic hardships, lost revenue and loss of employees, Sun has split its software ...
|
Adobe steers Flash toward RIA implementation
At this year's Adobe MAX Conference, the focus was on Flash, this time making Flash more o...
|
BigLever builds a bridge to SCM with Gears
The Gears Universal Configuration Management Bridge allows CM systems to integrate with Ge...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
Transform your app-dev quality by involving the whole community in testing
As the saying goes, the more eyes you have on software, the shallower the bugs. That’...
|
Build your dev and test labs for less – a lot less – with virtualization
You don’t have the budget to equip developers and software test teams with all the har...
|
Software Common Hacks and Counterattacks: A Guide to Protecting Software Products against the Top 7 Piracy Threats
Software piracy continues to be a growing epidemic. This white paper examines prevalen...
|
By Andrew Binstock
July 15, 2008 —
Behavior-Driven Development (BDD) sounds like either a modern theory of raising children or yet another way to mess with how programmers write code. It is the latter, but fortunately, unlike other xDD methodologies, it suggests only small changes to the way you currently do things. In its simplest form, BDD specifies the behavior of code and tries to have the code be expressive of that behavior, rather than maintaining a disconnected relationship between specification and implementation.
Let me illustrate. Behaviors are frequently expressed with keywords, such as: given, when, then and should. So, for example: given the 2008 tax tables, when a head of family has taxable income of less than US$12,000, then the tax should be $0. At a lower level that is closer to code: given a new linked list, then the list should be empty. And: given an empty linked list, when we add an item, then the list should not be empty.
At first blush, this might seem like another way of writing an if/then statement, save with a level of verbosity that exceeds COBOL. True, but that misses the point: First, you can define your scenarios, then insert the code into the scenarios that make it happen. Tools, such as easyb (which uses the JVM scripting language Groovy), enable code to be inserted into the scripts resulting in a very readable explanation of what is being done. Here is an example from the easyb site that illustrates the process.
Starting with the requirements articulated with BDD-style language: Given that a user mistypes a ZIP code, and given the ZIP code-validation service is up and running, when validation is performed, then the service should indicate the ZIP code is invalid.
In easyb, the implementation is woven into the constraints, and the result is:
given "an invalid zip code", {
invalidzipcode = "221x1"
}
and "given the zipcodevalidator is initialized", {
zipvalidate = new ZipCodeValidator()
}
when "validate is invoked with the invalid zip code", {
value = zipvalidate.validate(invalidzipcode)
}
then "the validator instance should return false", {
value.shouldBe false
}
Notice that the code implementation is specified between the braces. Easyb knows how to sequence that code correctly so that this works as expected. (For pure Java developers, Concordion does something similar.)
At this point, you might still be wondering what the advantage would be of the extra keystrokes. They are in fact manifold.
Perhaps most important is the ability to have real communication with the user about the code. For example, you can sit down with the user and capture all the various requirements in a series of scenarios. Then, as you place the needed method calls into the requirements, you have a good sense that your code is indeed matching the stipulated requirements. Moreover, the user can also see that the requirements have been implemented, as each one has matching method calls. This last point is important because it gives the user or manager a way to look at code in a reader-friendly fashion.
The benefits of BDD are not limited to user-developer communications. They also show up in a big way in unit testing. The previous example could easily be used to specify a unit test. In fact, unit-testing frameworks have begun adding BDD-like syntactical sugar.
For example, version 4.4 of JUnit contains the Hamcrest extensions, which confer far greater readability on JUnit tests. Those extensions were originally a popular part of JMock, the mock object library. (To use Hamcrest, download JUnit 4.4 and statically import org.hamcrest.CoreMatchers.* and org.junit.matchers.JUnitMatchers.* into your test classes.)
Then you can write far more readable unit tests. For example, you can test that x is(notANumber()) or that a collection hasItems(x,y,z) or that it hasKey(x). Not only does this simplify having to look up methods of various collections, but it also makes the intent of the test clearer.
For myself, this is a boon. Occasionally, I have made a change that makes a long-ago test fail. When I go back to the code, I struggle to recall exactly what I am doing in the test, and I have to consult the code I’m testing. In part, this is because tests don’t provide nearly the opportunity for pellucid coding that standard code does. The Hamcrest extensions make it easier to see at a glance what I was trying to do.
The extent to which BDD enters into the mainstream depends on the willingness of developers to write code more to obtain clarity. For my money, improved user communication and increased test legibility are well worth it.
Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at binstock.blogspot.com.
Related Search Term(s): Software development
Share this link: http://sdtimes.com/link/32488