To explore strange new worlds, to seek out new life and new civilisations, to boldly go where no man has gone before.” Just like the crew of the USS Enterprise, we explore the IT universe – seeking out new solutions, new technologies, and frameworks – from which we can learn to help us work better and more efficiently. We do this to create more functional and usable software for our customers, to put a big smile on their faces, and maybe – if we do our job really well – to make them stand back and admire what we have crafted. I was lucky enough to work in BDD (Behaviour Driven Development) quite early in his career, but I also had the misfortune to see how this great idea so often tends to fail. In my presentation I wanted to show what it is like working with BDD and what value can it give to business people. Finally I would like to propose an effective, alternative solution for well-known BDD tools, which is „Spock” – a convenient, lightweight framework, based on the Groovy language.

1. Star Trek:
BDD Enterprise
Tomek Dubikowski

2. let’s have a small trip around the universe

3. every ship needs
a captain

5. ready? steady?
go

6. first stop
planet chaos

7. technology and business
don’t talk at all

8. requirements hell
tech people business

10. second stop
planet waterfall

11. the silos kingdom

12. the dark lords

13. documentation is the main
source of knowledge
CR - 271
CR - 228
CR - 419
CR - 56
CR - 94
CR - 382
CR - 253
CR - 212
CR - 199
CR - 158

15. what if I told you that you can know
how the system works based on
how it actually works?

16. third stop
planet agile

17. working software over comprehensive
documentation

19. test scenario describes system behavior
green test means that system
actually behaves as described
red test means that system
doesn’t behave as described

21. tests vs documentation

22. fourth stop
BDD moon

23. beer
driven
development

24. behavior driven development
think how
your system
should
behave
create test
scenario for
the behavior
development
team
implements
the behavior
ok, genius
wait a minute
given – when – then

25. not sure if BDD

26. is not just TDD

27. @Test
public void
shouldDoSomethingWhenSomething() {
// given
...
// when
...
// then
...
}
my unit tests are like that

28. BDD is like TDD if…

30. BDD
TDD
test first
unit testing
• analysis
• design
• code / test
• code / test

31. think how
your system
should
behave
create test
scenario for
the behavior
development
team
implements
the behavior
i do the same stuff in excel

32. where is the difference

33. where is the difference

34. aww, but this is technical stuff

35. aww, but this is technical stuff
unit
integration
system

36. a little twist
story
file

37. Narrative:
As account user I want to make money transfer on my account
Scenario: Outgoing transfer from user account
Given: User has 100$ on his account
When: User makes a 50$ transfer to another account
Then: User has 50$ on his account
And: Another account state has increased by 50$
a little twist
story
file

38. reports = current documentation
green
systems
behaves like
described in
scenario

39. use the right tools

40. story
file
code file
how (most of) these work
implements

41. two files to maintain
high coupling

42. @Then("the value returned is empty")
public void theValueIsEmpty() {
...
}
@Then("the value returned is $value")
public void theValueIs(String value) {
...
}
the actual code
regex matching
jre
dependent

43. IDE integration is a pain

44. heavyweight players
only for system test level

45. hello again, captain spock
use spock, it’s better

47. groovy is groovy because:
• dynamic language
• functional style
• easy for java developers
• syntax boosts
• syntax simplifications

48. powerful for DSLs
even spock’s syntax is DSL

49. business use case
Narrative:
Customers do the shopping in our shop. When he checks out we
need to calculate the right delivery charge depending on the
total value of the basket, delivery date and if customer has
bought delivery subscription.
Scenario: Shopping for more than 40£ should not be charged
Given: Customer has products for 50£ in the basket
When: Customer checks out
Then: No delivery charge is added to the receipt
And: Email with receipt is sent to the customer
let’s migrate it to spock

50. Narrative:
Customers do the shopping in our shop. When he checks out we
need to calculate the right delivery charge depending on the
total value of the basket, delivery date and if customer has
bought delivery subscription.
@Narrative(‘’’
Customers do the shopping in our shop. When he checks out we
need to calculate the right delivery charge depending on the
total value of the basket, delivery date and if customer has
bought delivery subscription.
‘’’)
@Title(‘Delivery charge specification’)
@Narrative(‘’’
Customers do the shopping in our shop. When he checks out we
need to calculate the right delivery charge depending on the
total value of the basket, delivery date and if customer has
bought delivery subscription.
‘’’)
class DeliveryChargeTest extends Specification {
first things first – narrative
not that technical

51. Scenario: Shopping for more than 40£ should not be charged
Given: Customer has products for 50£ in the basket
When: Customer checks out
Then: No delivery charge is added to the receipt
And: Email with receipt is sent to the customer
second step – scenario
def ‘Shopping for more than 40£ should not be
charged’ () {
given: ‘Customer has products for 50£ in the basket’
when: ‘Customer checks out’
then: ‘No delivery charge is added to the receipt’
and: ‘Email with receipt is sent to the customer’
}
def ‘Shopping for more than 40£ should not be
charged’ () {
given: ‘Customer has products for 50£ in the basket’
<code>
when: ‘Customer checks out’
<code>
then: ‘No delivery charge is added to the receipt’
<code>
and: ‘Email with receipt is sent to the customer’
<code>
}

53. def ‘Shopping for more than 40£ should not be charged’ () {
given: ‘Customer has products for 50£ in the basket’
Customer customer = aCustomer.withBasket(aBasket.with(...)).build();
when: ‘Customer checks out’
Order order = customer.checkOut(new Date());
then: ‘No delivery charge is added to the receipt’
assertThat(order.getDeliveryCharge()).isEqualTo(0);
and: ‘Email with receipt is sent to the customer’
verify(emailService).sendMessage(customer.getEmailAddres(),
anyMessage())
}
give me a try, please
def ‘Shopping for more than 40£ should not be charged’ () {
given: ‘Customer has products for 50£ in the basket’
Customer customer = aCustomerWith50PoundsWorthBakset();
when: ‘Customer checks out’
Order order = chechout(customer);
then: ‘No delivery charge is added to the receipt’
assertThatDeliveryChargeIsZero(order);
and: ‘Email with receipt is sent to the customer’
verifyThatEmailWasSentTo(customer);
}
def ‘Shopping for more than 40£ should not be charged’ () {
given: ‘Customer has products for 50£ in the basket’
def customer = ‘a customer with 50£ worth basket’()
when: ‘Customer checks out’
def order = checkout customer
then: ‘No delivery charge is added to the receipt’
‘delivery charge of’ order == 0
and: ‘Email with receipt is sent to the customer’
‘email was sent to’ customer
}
def ‘Shopping for more than 40£ should not be charged’ () {
given: ‘Customer has products for 50£ in the basket’
customer with basket of value 50
when: ‘Customer checks out’
customer checkouts order
then: ‘No delivery charge is added to the receipt’
delivery charge == 0
and: ‘Email with receipt is sent to the customer’
email sent to customer
}

54. what we achieved?but we want more

55. file to maintain

56. IDE integration
direct link between steps and
implementation

57. fits all testing levels

58. can business work alone?

60. final thoughts

61. spock for BDD
spock for unit testing

62. .net frameworks
• specflow
• NSpec / StoryQ
• xbehave.net
• StoryTeller

63. BDD makes business and tech
people communicate better

64. communication is the key to
success

65. thank youtomek dubikowski
@tdubikowski
agilehabits.wordpress.com