Hi,
BDD and TDD stands for different purposes with different actors.
In BDD, stakeholders work on the functionalities of software units
(coarse grain, black-box approach) whereas on TDD developers work on the
object's features (fine-grain, white-box approach) that made the
functionalities. So, the tooling in BDD should be different of the
tooling used in TDD (BDD is more high-level than TDD).
In BDD each functionalities are describes as :
As a <role>
I want <some feature>
So that <I gain a benefit>
And the functionality is described in different scenarios (nominal and
error ones) :
Given <some initial context>
When <an event occurs>
Then <ensure some outcomes>
Basic example:
/As a/ customer,
/I want/ to withdraw cash from an ATM,
/so that/ I don’t have to wait in line at the bank.
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
In fact, a useful and good BDD tool must provide :
* a way to define a set of initial data
* a DSL to define the functionalities and for each of them to express
the scenarios according to the schema above
* an engine that feeds automatically the scenario from the data set
and that outputs the result.
Miguel Moquillon
Le 20/04/2015 12:02, Christophe Demarey a écrit :
Hi,
With BDD a current test practice is to start method names with 'should'.
It is not yet possible in Pharo but easily do-able (update of TestCase and some
Nautilus methods).
I would like that Pharo detects tes methods all methods of a class subclassing
(directly or not) TestCase AND starting with either 'test' or 'should'.
I also would like to add 'deny' to not use 'shouldNot' but here I'm not sure.
WDYT?
Christophe.
