This document discusses different types of testing methodologies: TDD (Test Driven Development), ATDD (Acceptance Test Driven Development), BDD (Behavior Driven Development), and DDD (Domain Driven Design). It explains that BDD builds upon TDD and ATDD by making tests more business-readable and team-driven. The document then provides examples of implementing BDD using Cucumber and Gherkin syntax in Java/Coffeescript projects.

1. S(p)exy testing in Coffeescript and Node.js
Aaron Murray Nicholas Vaidyanathan
@WeAreFractal @SWVisionary

3. We’re glad you’re here!
But you obviously care about tests, so
let’s talk about some terminology…

4. TDD, ATDD, BDD, DDD?
That’s a lot of DD’s
• TDD = Test Driven Development – Development Methodology, write tests
first, test using xUnit – make sure the code works
• ATDD = Acceptance Test Driven Development – business-readable, Team-
driven, tests owned by client – make sure the features are correct
• BDD = Behavior Driven Development – Team-driven, “Should”, “Given,
When, Then” – extends TDD and incorporates ATDD
• DDD = Domain Driven Design – outlines the idea of the Ubiquitous
Language used between non-technical stakeholders and developers

5. Wait, DDD? Why?
• What does DDD have to do with BDD?
• Proper architecture helps you
– set up smallest possible services
– Focus on nouns and verbs
– Describes behavior, which drives BDD process
• Testing IS Design!!!!
• GOOD ARCHITECTURE IS PIVOTAL TO
SUCCESSFUL BDD!

6. In the beginning, there was TDD
• Test Driven Development
– Rediscovered by Kent Beck @kentbeck
• Simple Process
– Test
– Code
– Refactor

7. Tests looked like this
• http://junit.sourceforge.net/doc/cookbook/cook
book.htm

8. Then we came to ATDD
• TDD is a programming practice, not
a testing technique.
• Acceptance Test Driven
Development (ATDD) also involves
creating tests before code
• tests represent expectations of
behavior the software should have.
• team creates one or more
acceptance-level tests for a feature
before beginning work on it.
• team discusses tests and captures
them when working with the
business stakeholder(s) to
understand a story on the backlog.
• http://testobsessed.com/wp-
content/uploads/2011/04/atddexample.pdf

9. And BDD
• Evolved out of established agile practices and is designed to
make them more accessible and effective for teams new to
agile software delivery.
• Premises
– Test method names should be sentences
– A simple sentence template keeps test methods focused
– An expressive test name is helpful when a test fails
– “Behaviour” is a more useful word than “test”
– Determine the next most important behaviour
– Requirements are behaviour,too
– BDD provides a “ubiquitous language” for analysis
– Acceptance criteria should be executable
• http://dannorth.net/introducing-bdd/

10. BDD Breakdown
Fundamentally Two Types of BDD Tools
Business-readable output
– Replacement/Extension for TDD at the Unit-testing level
– Artifacts owned by developers (code)
– Provides other stakeholders with reports after developers have done the work
– Gspec, Spock, EasyB
Business-readable input
– Based on Acceptance Testing – coarse-grained features
– Artifacts owned by client
– Stakeholder involvement before developers have done any work
– Cucumber, FitNesse
Not exclusive – can and probably need to be combined

11. EasyB
business-readable output
input output
scenario "Two amounts with the same currencies are 2 scenarios executed successfully.
added", {
given "Two different amounts with the same Story: money
currencies", {
money1 = new Money(12, "CHF") scenario Two amounts with the same
money2 = new Money(14, "CHF")
currencies are added
given Two different amounts with
expected = new Money(26, "CHF") the same currencies
} when Add given amounts
when "Add given amounts" , { then New amount is sum of two
result = money1.add(money2) given ones
} scenario Two amounts with different
then "New amount is sum of two given ones", { currencies are added
result.equals(expected).shouldBe true given Two amounts with different
} currencies
when Add given amounts
}
then Operation should fail
…
<<truncated>>

12. Step 1: write your feature
Addition.feature
Feature: Addition
In order to avoid silly mistakes
As a math idiot
I want to be told the sum of two numbers
Scenario: Add two numbers
Given I have entered <input_1> into the calculator
And I have entered <input_2> into the calculator
When I press <button>
Then the result should be <output> on the screen
Examples:
| input_1 | input_2 | button | output |
| 20 | 30 | add | 50 |
| 2 | 5 | add | 7 |
| 0 | 40 | add | 40 |

13. Step 2: step definition
CalculatorSteps.groovy
this.metaClass.mixin(cuke4duke.GroovyDsl)
Before() {
calc = new Calculator()
}
Given(~"I have entered (d+) into the calculator") { int n ->
calc.push n
}
When(~"I press (w+)") {op ->
result = calc.send(op)
}
Then(~"the result should be (.*) on the screen") { int r ->
assert r == result
}

14. Step 4: write code to make it pass
Calculator.groovy
class Calculator {
def numbers = []
void push(number) {
numbers << number
}
def send(operation) {
def result
switch (operation) {
case "add":
result = add()
}
numbers.clear()
result
}
private def add() {
numbers.sum()
}
}

15. BDD in Java/Coffeescript and Node
• Best available frameworks
– Jasmine
– Vows
• Comparison
– http://stackoverflow.com/questions/4115492/jav
ascript-bdd-vows-kyuri-vs-jasmine
• So…

16. Introducing
• Built in Node.js natively
• Written in CoffeeScript
• Modular, clean architecture
• Designed to dramatically simplify the BDD process
• Provides an annotation based mechanism for
defining your tests

17. Example spec

19. Benefits
• Clean syntax
• Doesn’t pollute global namespace
• Flexibility
• Give it a try
– https://github.com/wearefractal/spex
• LIVE DEMO