Recently I’ve grown increasingly fond of the concepts embodied in the “Behavior Driven Development” (BDD) outgrowth of “Test Driven Development” (TDD) and “Domain Driven Design” (DDD) . BDD is a neat twist on TDD and DDD that strives to more closely tie automated tests with both the “ubiquitous language” terminology espoused in DDD, along with an Agile-style tight integration with business users in defining the TDD tests.
A great challenge with implementing TDD I think has been the difficulty in writing tests first — often driven by a difficulty in amassing sufficient detail in terms of requirements and acceptance tests to truly generate specifications for test-first development. Too often TDD ends up being a case of writing tests after-the fact to test code which we’ve written to incomplete conceptions of what the code needs to do.
A number of toolkits have emerged recently for BDD — and recent reading at http://www.agiledeveloper.com (which has some truly awesome content) led me to a PPT on BDD using easyb. Easyb provides some tools (built around Groovy) for restructuring your code to have unit/acceptance tests written in a smooth DSL — this especially appeals to me given it’s close congruence with the way my team at CampusEAI has moved to handling our requirements and user-stories.
Cutting to the chase, easyb lets you express acceptance tests **in code** that looks like:
1
2
3
4
5
6
7
8
9
10
11
| narrative 'description', {
as_a 'account holder'
i_want 'depost money'
so_that 'whatever benefit...'
}
scenario 'deposit money', {
given 'account 12345'
when 'deposit 10000'
then 'balance of account 12345 goes up by $10000'
} |
These scenarios can then be directly tied to acceptance tests in code, and there’s even nice support for putting them in without implmeentations to be marked as “pending”. The overall sytax looks inspired by RSpec, but tied into Java. There’s even some nice reporting builtin to handle producing reports — plaintext here:
9 behavior steps executed successfully
Story: blackjack
scenario tie game when cards are dealt but dealer gets higher card
given a game a blackjack game and both players have a score of 10
when the dealer gets an Ace and you get a 10
then the dealer should win
scenario tie game when cards are dealt but player gets higher card
given a game a blackjack game and both players have a score of 10
when the dealer gets a 10 and you get an Ace
then the player should win
— looks like this would hook in well to Maven to incorporate into something like a Maven site/build process, with some tasks existing — dreaming about a report in Hudson to graph this….
BDD with easyb
Tags: about · age · agile · ANT · BDD · business · CampusEAI · cas · ci · development · easyb · groovy · HTML · hudson · integration · it · java · maven · merge · post · programming · tax · TDD · test · tools · ui
Recently I’ve grown increasingly fond of the concepts embodied in the “Behavior Driven Development” (BDD) outgrowth of “Test Driven Development” (TDD) and “Domain Driven Design” (DDD) . BDD is a neat twist on TDD and DDD that strives to more closely tie automated tests with both the “ubiquitous language” terminology espoused in DDD, along with an Agile-style tight integration with business users in defining the TDD tests.
A great challenge with implementing TDD I think has been the difficulty in writing tests first — often driven by a difficulty in amassing sufficient detail in terms of requirements and acceptance tests to truly generate specifications for test-first development. Too often TDD ends up being a case of writing tests after-the fact to test code which we’ve written to incomplete conceptions of what the code needs to do.
A number of toolkits have emerged recently for BDD — and recent reading at http://www.agiledeveloper.com (which has some truly awesome content) led me to a PPT on BDD using easyb. Easyb provides some tools (built around Groovy) for restructuring your code to have unit/acceptance tests written in a smooth DSL — this especially appeals to me given it’s close congruence with the way my team at CampusEAI has moved to handling our requirements and user-stories.
Cutting to the chase, easyb lets you express acceptance tests **in code** that looks like:
2
3
4
5
6
7
8
9
10
11
as_a 'account holder'
i_want 'depost money'
so_that 'whatever benefit...'
}
scenario 'deposit money', {
given 'account 12345'
when 'deposit 10000'
then 'balance of account 12345 goes up by $10000'
}
These scenarios can then be directly tied to acceptance tests in code, and there’s even nice support for putting them in without implmeentations to be marked as “pending”. The overall sytax looks inspired by RSpec, but tied into Java. There’s even some nice reporting builtin to handle producing reports — plaintext here:
Story: blackjack
scenario tie game when cards are dealt but dealer gets higher card
given a game a blackjack game and both players have a score of 10
when the dealer gets an Ace and you get a 10
then the dealer should win
scenario tie game when cards are dealt but player gets higher card
given a game a blackjack game and both players have a score of 10
when the dealer gets a 10 and you get an Ace
then the player should win
— looks like this would hook in well to Maven to incorporate into something like a Maven site/build process, with some tasks existing — dreaming about a report in Hudson to graph this….