Monday, April 09, 2007

Behaviour Driven Development

Behaviour Driven Development swept in like a breathe of fresh air.

Basically, it's unit testing (ala JUnit), but at a higher level - it's also an implementation of capturing user stories.

For example:
Scenario 1: Account is in credit
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned

becomes
public class AccountIsInCredit implements Given {
public void setup(World world) {

}
}

public class CardIsValid implements Given {
public void setup(World world) {

}
}

public class CustomerRequestsCash implements Event {
public void occurIn(World world) {

}
}
... and so forth.

All of your assumptions then get instantiated, and evaluated, before passing off the results to the outcome handling bits.

Doesn't sound like much, does it, but I'm always running into problems like this.


public function testDoesntAllowDatesInThePast() {
$foo = $this->document;

try {
$foo->Date = "1900-01-01";

$xml = $foo->asXML();

$this->fail("SanityFailureException expected!");
} catch (SanityFailureException $sfe) {

}
}

public function testDoesntAllowDatesInTheFuture() {
//... The same expectations are checked, across 95 other tests as well.
}


With JBehave, I'd be able to piece together several different pieces of setup - make the objects, set values x,y,z; call some other function over there; and then inspect the results I get back at a much higher level of detail.
I could simply have a "does it validate against an XSD" outcome written, as well as two or three other fine grained ones.

Using Agile Documentation, you can make something somewhat comprehensible to business people; as well.

The above example would become
XMLDocument
- Doesnt allow dates in the past
- Doesnt allow dates in the future


Go and have a read of Dan North's blog for more about this
Post a Comment