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.