Test & Behavior Driven

Development

or how to work with tests

March 27 2015

Legacy code VS innovation

Cost

of c

hang

e

Time

Low technical debt High technical debt

Test-Driven Development

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

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

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.

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

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

TDD is a good approachTime spent on tickets but…

Level of confidence that can be placed into it

Risk of introducing regressions

Working with legacy code is safer

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

but it’s not enoughBusiness goals

Squad projects

User stories

Something is missing here

Code

Leve

l of d

etai

ls

Unit tests

Company level

Squad level

Story level

Behavior-Driven Development

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

Principles of Behavior-Driven Development1. 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.

Behavior-Driven Development

Write the test cases

Run all tests

Refactor & move on

all tests succeed

it failsWrite the code

ship the story

“A [role] can [do something] (so that [benefits]).”

But… what does it do exactly?

User story

“(If [given state],) when [event], then it should [do something].”

Acceptance criteria and scenarii

Continue with scenario 2…

new

How to work with BDDBusiness goals

Squad projects

User stories

Acceptance criteria

Scenarii

Code

Leve

l of d

etai

ls

Unit tests

Company level

Squad level

Story level

How to work with BDDUser 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 2Scenario 3

Other tests:Scenario 4Scenario 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

Does this feature really need tests?

YES so don’t forget to include them into the ticket

estimate, it costs time

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

Example of story: Upload a videoA 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.

Upload a video: scenario 1describe '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

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

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

Thank you