Test & behavior driven development
-
Upload
tristan-libersat -
Category
Engineering
-
view
196 -
download
0
Transcript of Test & behavior driven development
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