Behavior driven dev

TDD

the tests are usually mainly state-based – asserting values at the end of the test

use mock objects to set and verify expectations about how objects will interact. The state becomes a side-issue.
TDD code written in this way is characterized by narrow, well-named interfaces describing the roles objects play for one another.

Each “test method”  takes the form of a sentence saying what the object should do.

Example

Story: Account Holder withdraws cash

As an Account Holder
I want to withdraw cash from an ATM
So that I can get money when the bank is closed

Using the given-when-then template, the first two scenarios might look like this:

Scenario 1: Account has sufficient funds
Given the account balance is $100
 And the card is valid
 And the machine contains enough money
When the Account Holder requests $20
Then the ATM should dispense $20
 And the account balance should be $80
 And the card should be returned

Scenario 2: Account has insufficient funds
Given the account balance is $10
 And the card is valid
 And the machine contains enough money
When the Account Holder requests $20
Then the ATM should not dispense any money
 And the ATM should say there are insufficient funds
 And the account balance should be $20
 And the card should be returned

Scenario 3: Card has been disabled
Given the card is disabled
When the Account Holder requests $20
Then the ATM should retain the card
And the ATM should say the card has been retained

Scenario 4: The ATM has insufficient funds