behavior driven development - a recap (@ symfony bucharest meetup)

A L I N P A N D I C H I -

BEHAVIOR DRIVEN DEVELOPMENT A RECAP

SOFTWARE DEVELOPER, TRAINER AND

COACH @ MOZAICWORKS

BDD HAS GOT A BIT

CONFLATED WITH

ACCEPTANCE TESTING IN

THE PHP COMMUNITY

BECAUSE OF TOOLS LIKE

BEHAT AND

CODECEPTION .

A R E D D I T U S E R

BDD IS MORE

ABOUT WORKFLOW

AND MINDSET

RATHER THAN

TOOLING .

A N O T H E R R E D D I T U S E R

OVER TIME , BDD HAS

GROWN TO ENCOMPASS

THE WIDER PICTURE OF

AGILE ANALYSIS AND

AUTOMATED

ACCEPTANCE TESTING .

D A N N O R T H

WE MUST GO BACK TO TDD

T O U N D E R S T A N D B D D . . .

HTTP://BLOG.THEFIREHOSEPROJECT.COM/POSTS/TEST-DRIVEN-DEVELOPMENT-RSPEC-VS-TEST-UNIT/

TYPICAL DEV PROBLEMS IN TDD :

- WHERE TO START

- WHAT TO TEST

- WHAT NOT TO TEST

- HOW MUCH TO TEST

- WHAT TO CAL L THE IR TESTS

- HOW TO UNDERSTAND WHY

A TEST FA I L S

S T E P S T O W A R D S B D D

TEST METHOD NAMES SHOULD BE SENTENCES

01

S T E P S T O W A R D S B D D

TEST METHOD NAMES SHOULD BE SENTENCES

01

public class CustomerLookupTest extends TestCase {

   testFindsCustomerById() {

   }

   testFailsForDuplicateCustomers() {

   }

}

S T E P S T O W A R D S B D D

THE CONVENTION OF STARTING TEST METHOD NAMES

WITH THE WORD “SHOULD”

02

S T E P S T O W A R D S B D D

REMOVED ANY REFERENCE TO TESTING AND REPLACED

IT WITH A VOCABULARY BUILT AROUND VERIFYING

BEHAVIOUR

03

S T E P S T O W A R D S B D D

03

public class CustomerLookupTest extends TestCase {

   testFindsCustomerById() {

   }

   testFailsForDuplicateCustomers() {

   }

}

CustomerLookup

- should find customer by id

- should fail for duplicate customers

- ...

S T E P S T O W A R D S B D D

DISCOVERED THE CONCEPT OF BUSINESS VALUE

04

I HAD ALWAYS BEEN AWARE

THAT I WROTE SOFTWARE FOR

A REASON ,

BUT I HAD NEVER REALLY

THOUGHT ABOUT THE VALUE

OF THE CODE I WAS WRITING

RIGHT NOW .

D A N N O R T H

S T E P S T O W A R D S B D D

WHAT ’S THE NEXT MOST IMPORTANT THING

THE SYSTEM DOESN ’T DO?

05

BUT THAT ’S JUST LIKE

ANALYSIS .

Y O U , R I G H T N O W

S T E P S T O W A R D S B D D

APPLY ALL OF THIS BEHAVIOUR-DRIVEN THINKING

TO DEFINING REQUIREMENTS

S T E P S T O W A R D S B D D

DEVELOP A CONSISTENT VOCABULARY FOR ANALYSTS ,

TESTERS , DEVELOPERS , AND THE BUSINESS . . .

S T E P S T O W A R D S B D D

. . .ELIMINATING SOME OF THE AMBIGUITY AND

MISCOMMUNICATION THAT OCCUR WHEN TECHNICAL

PEOPLE TALK TO BUSINESS PEOPLE .

A S T A R T I N G P O I N T .

USER STORY TEMPLATES

As a [X] I want [Y] so that [Z]

A S T A R T I N G P O I N T .

USER STORY TEMPLATES

As a [X] I want [Y] so that [Z]

I want [some feature] So that... [I just do, ok?]

A S T A R T I N G P O I N T .

USER STORY TEMPLATES

As an Endava employee

I want to ride an elevator to my office

So that I don't sweat climbing 10 floors using the stairs.

IT SAYS NOTHING ABOUT THE BE BEHAVIOUR OF

THE ELEVATOR

As an Endava employee I want to ride an elevator to my office So that I don't sweat climbing 10 floors using the stairs.

A STORY’S BEHAVIOUR IS SIMPLY ITS

ACCEPTANCE CRITERIA

As an Endava employee I want to ride an elevator to my office So that I don't sweat climbing 10 floors using the stairs.

DESCRIBE THE ACCEPTANCE CRITERIA IN TERMS

OF SCENARIOS

As an Endava employee I want to ride an elevator to my office So that I don't sweat climbing 10 floors using the stairs.

DESCRIBE THE ACCEPTANCE CRITERIA IN TERMS

OF SCENARIOS

Given some initial context,

When an event occurs,

then ensure some outcomes.

ACCEPTANCE CRITERIA IN TERMS OF SCENARIOS

Scenario:

Given I am on the 0 floor

And the elevator is on the 0 floor

And a call for 3 floor is registered

And a call for -1 floor is registered

When I call elevator

And the elevator operates

Then the elevator opens door on -1 level

Then the elevator opens door on 0 level

Then the elevator opens door on 3 level

F I N A L L Y . . .

ACCEPTANCE CRITERIA COULD BE EXECUTABLE

THE VISION IS TO HAVE A

ROUND-TRIP EDITOR SO THAT

BA`S AND TESTERS CAN

CAPTURE STORIES IN A

REGULAR TEXT EDITOR THAT

CAN GENERATE STUBS FOR

THE BEHAVIOUR CLASSES , ALL

IN THE LANGUAGE OF THE

BUSINESS DOMAIN .

D A N N O R T H

BDD PRACTITIONERS

EXPLORE , DISCOVER , DEFINE ,

THEN DRIVE OUT THE DESIRED

BEHAVIOUR OF SOFTWARE

USING CONVERSATIONS ,

CONCRETE EXAMPLES AND

AUTOMATED TESTS .

M A T T W Y N N E

HTTPS://TWITTER.COM/ANTONYMARCANO/STATUS/894822480141066240

A GROUP OF PEOPLE

SPECIFYING HOW

SOFTWARE SHOULD

BEHAVE BEFORE

IMPLEMENTING IT .

D A N N O R T H

N O T T H I S !

HTTPS://TWITTER.COM/SEBROSE/STATUS/913080462444253184

C E R T A I N L Y N O T T H I S !

HTTP://LABS.IG.COM/CODE-COVERAGE-100-PERCENT-TRAGEDY

R E A D M O R E :

HTTPS : / /DANNORTH .NET/ INTRODUCING-BDD/

HTTP : / /LABS . IG .COM/CODE-COVERAGE-100-

PERCENT-TRAGEDY

HTTPS : / /WWW .YOUTUBE .COM

/WATCH?V=L95DSKM5FBY

HTTPS : / /GITHUB .COM/MSEKNIBILEL /ELEVATOR-

BDD-KATA

T H A N K

Y O U !

A L I N P A N D I C H I

@ALINPANDICHI

ALIN.PANDICHI@MOZAICWORKS.COM