This document discusses test-driven development (TDD) and behavior-driven development (BDD). It explains that TDD focuses on writing unit tests before code, while BDD focuses on testing user behaviors and acceptance criteria. BDD uses user stories and scenarios to describe what a feature should do at a high level before writing tests and code. The document provides an example of a user story for uploading a video, along with scenarios to test the behavior. It emphasizes that both developers and product owners should collaborate on writing acceptance criteria in the form of scenarios to validate stories.

1. Test & Behavior
Driven
Development
or how to work with tests
March 27 2015

2. Legacy code VS innovation
Costofchange
Time
Low technical debt High technical debt

3. Test-Driven Development

4. What is a unit test?
“A unit test is an automated piece of code that
checks a single assumption about the behavior
of a unit of work”
artofunittesting.com

5. Sooo… what is a unit of work?
“A unit of work can span a single method, a
whole class or multiple classes working
together to achieve one single logical purpose
that can be verified”
artofunittesting.com

6. Example of Unit Test: DateTest
TEST 1: EMPTY DATE
Empty string, null or 0
are not valid parameters
and should return 0.
TEST 2: VALID DATE
time() is a valid
parameter and should
return a valid date.

7. Example of Unit Test: DateTest
class DateTest extends PHPUnit_Framework_TestCase
{
public function testEmptyDate()
{
$this->assertEquals(Date::getInstance('')->getTime(), 0, 'empty time returns 0');
$this->assertEquals(Date::getInstance(null)->getTime(), 0, 'null time returns 0');
$this->assertEquals(Date::getInstance(0)->getTime(), 0, 'zeroified time returns 0');
$this->assertNotEquals(Date::getInstance('')->getTime(), '', 'empty time does not
output to empty string');
}
}
real test written is PHP using PHPUnit Framework

8. The rules of Test-Driven Development
(Re)write a unit test
Run
the test
Write the code
Run all
tests
Refactor &
move on
it succeeds
all tests
succeed
it fails
it fails
repeat
for both core & front developers
ship the story

9. TDD is a good approach
Time spent on tickets but…
Level of confidence that can be placed into it
Risk of introducing regressions
Working with legacy code is safer

10. but it’s not enough
• Tech-oriented tests
• It doesn’t explain what the feature should do
• A ticket can pass the tests and still break the
user experience

11. but it’s not enough
Business goals
Squad projects
User stories
Something is
missing here
Code
Levelofdetails
Unit tests
Company level
Squad level
Story level

12. Behavior-Driven Development

13. What is a functional test?
“A functional test (or e2e test) is an automated
way of checking software to ensure that it has
all the required functionality that’s specified
within its functional requirements”
techopedia.com

14. Principles of Behavior-Driven Development
1. BDD focuses on
the behavioural
aspect of the
feature rather
than its
implementation.
2. BDD gives a clear
understanding as
to what a feature
should do from
technical,
business/product
and customer
standpoints.
3. BDD allows both
the developer and
product owner to
work together on
requirements
analysis.

15. Behavior-Driven Development
Write the test cases
Run all
tests
Refactor &
move on
all tests
succeed
it fails
Write the code
ship the story

16. “A [role] can [do something]
(so that [benefits]).”
But… what does it do exactly?
User story

17. “(If [given state],) when [event],
then it should [do something].”
Acceptance criteria and scenarii
Continue with scenario 2…
new

18. How to work with BDD
Business goals
Squad projects
User stories
Acceptance criteria
Scenarii
Code
Levelofdetails
Unit tests
Company level
Squad level
Story level

19. How to work with BDD
User Story:
A [role]
can [do something]
so that [benefits]
Acceptance criteria:
Scenario 1:
If [given state]
and [other state]
when [event]
then it should [do something]
and [another thing]
Scenario 2
Scenario 3
Other tests:
Scenario 4
Scenario 5
(Unit tests)
User stories remain the same
Acceptance criteria are the mandatory tests to validate the
story.
They should be written by both the product owner and the
developer before they start working on the ticket
Other tests are not here to validate the feature but to avoid
regressions and should test specific parts of the experience
Unit tests should not be described in the story, but present in
the code

20. Does this feature really need tests?
YES
so don’t forget to include them into the ticket
estimate, it costs time

21. Does this bug really need tests?
MAYBE
if it’s a recurrent or critical/blocker bug, you should
consider creating a test to avoid it

22. Example of story: Upload a video
A user can publish a video on his channel in order to increase his popularity.
SCENARIO 1
If the user is logged-in,
when he selects a video
file, it should upload it.
SCENARIO 2
If the user just selected a
video and fulfilled its
meta-data, when the
upload process is
completed, it should
publish the video.
SCENARIO 3
If the video is published,
when the user goes to its
player page, it should
display the video.

23. Upload a video: scenario 1
describe 'Upload a video', ->
it 'should upload a video', ->
uploadPage = new UploadPage()
login uploadPage.url
today = new Date()
videoName = 'Cool video for tests ' + today
uploadPage.uploadFile videoName
browser.sleep 3000
browser.getTitle().then (text) ->
expect(text).toEqual videoName
real test written is CoffeeScript using Jasmine Framework

24. Story life cycle
BEFORE
• Describe the acceptance
criteria in the ticket (dev
+ product)
WHILE
• The front developer needs to
implement acceptance criteria
alongside with the feature
code + some other tests (but
they are not required for the
feature validation)
• The core developer also needs
to implement unit tests for his
methods
AFTER
• The release process launches
all the acceptance criteria of
all features on a regular basis
to test all tickets together
release processall tests OK

25. What to do if a test fails?
Fix the feature
yes
no
Is the test still
relevant?
Rewrite the test Remove the test &
plan a feature killing
is the
feature still
relevant?
yes no

26. Thank you