Slide 1

Slide 1 text

Test-Driven Development Adrián Matellanes

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

What is TDD?

Slide 4

Slide 4 text

A development technique where you must first write a test that fails before you write new code that passes the new test

Slide 5

Slide 5 text

Kent Beck rediscovered this technique in the 1990s

Slide 6

Slide 6 text

What is a test?

Slide 7

Slide 7 text

A procedure intended to establish the quality, performance, or reliability of something.

Slide 8

Slide 8 text

talk(); $expected = "Hello world!"; $this->assertEquals($expected, $actual); unset($user); } }

Slide 9

Slide 9 text

talk(); $expected = "Hello world!"; $this->assertEquals($expected, $actual); unset($user); } } Setup

Slide 10

Slide 10 text

talk(); $expected = "Hello world!"; $this->assertEquals($expected, $actual); unset($user); } } Execution

Slide 11

Slide 11 text

talk(); $expected = "Hello world!"; $this->assertEquals($expected, $actual); unset($user); } } Validation

Slide 12

Slide 12 text

talk(); $expected = "Hello world!"; $this->assertEquals($expected, $actual); unset($user); } } Teardown

Slide 13

Slide 13 text

Testing Methods

Slide 14

Slide 14 text

Black box White box

Slide 15

Slide 15 text

Categories of Tests

Slide 16

Slide 16 text

Unit Integration Behavioral

Slide 17

Slide 17 text

Unit Behavioral Integration

Slide 18

Slide 18 text

Test Doubles

Slide 19

Slide 19 text

Dummy Fake Stub Spy Mock

Slide 20

Slide 20 text

TDD Schools

Slide 21

Slide 21 text

London School Detroit School

Slide 22

Slide 22 text

Why developers not writing tests?

Slide 23

Slide 23 text

No time No budget Write once project finishes We do not know how to write

Slide 24

Slide 24 text

“If it's worth building, it's worth testing. If it's not worth testing, why are you wasting your time working on it?” Scott Ambler

Slide 25

Slide 25 text

What is the goal of TDD?

Slide 26

Slide 26 text

Write clean code that works

Slide 27

Slide 27 text

“The only way to make the deadline — the only way to constantly go fast — is to keep the code as clean as possible at all times.” Robert C. Martin

Slide 28

Slide 28 text

What makes a design good?

Slide 29

Slide 29 text

The 7 Design Smells of Bad Code

Slide 30

Slide 30 text

Rigidity Fragility Immobility Viscosity Needless Repetition Opacity Needless Complexity

Slide 31

Slide 31 text

How TDD works?

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

Red Write a failing test

Slide 35

Slide 35 text

Green Make the test pass

Slide 36

Slide 36 text

Refactor Make it better

Slide 37

Slide 37 text

Technical Debt

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

“Perfect is the enemy of good.” Voltaire

Slide 40

Slide 40 text

Why do you test-drive code?

Slide 41

Slide 41 text

Predictability

Slide 42

Slide 42 text

Courage

Slide 43

Slide 43 text

Documentation

Slide 44

Slide 44 text

Cleaner Code

Slide 45

Slide 45 text

Gamification

Slide 46

Slide 46 text

Reduced debugging effort

Slide 47

Slide 47 text

More productive

Slide 48

Slide 48 text

Automated

Slide 49

Slide 49 text

Emergent Design

Slide 50

Slide 50 text

Coverage

Slide 51

Slide 51 text

Code coverage refers to the amount of code covered by test cases

Slide 52

Slide 52 text

The tragedy of 100% code coverage

Slide 53

Slide 53 text

assertEquals($expected, $result); } }

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

No content

Slide 56

Slide 56 text

No content

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

Best Practices

Slide 60

Slide 60 text

Keep the unit small Minimize assertions Start with the failing test case Fast running tests Avoid fragile tests Rerun all test cases on each failure Don’t introduce dependencies between tests Follow standard naming conventions Use mock objects

Slide 61

Slide 61 text

The Bad Parts

Slide 62

Slide 62 text

Hard to apply to existing legacy code Requirements misinterpretations False sense of security How many tests should you write? Complex scenarios Rapidly changing requirements Not having enough knowledge on unit testing and refactoring Restricted portability Writer/Reader with technical background

Slide 63

Slide 63 text

Behavior-driven development

Slide 64

Slide 64 text

Behavioural Test Unit Test

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

Scenario: Dispense $50 cash in multiple denominations Given I have $100 in my account And I have a card with the PIN 1234 And I push my card into the machine And I enter 1234 for my PIN And I push the button next to Withdrawal And I push the button next to Checking When I push the button next to $50 Then a $20 bill should be ejected by the cash dispenser And a $20 bill should be ejected by the cash dispenser And a $10 bill should be ejected by the cash dispenser

Slide 67

Slide 67 text

Scenario: Dispense $50 cash in multiple denominations Given I have $100 in my account And I have a card with the PIN 1234 And I push my card into the machine And I enter 1234 for my PIN And I push the button next to Withdrawal And I push the button next to Checking When I push the button next to $50 Then a $20 bill should be ejected by the cash dispenser And a $20 bill should be ejected by the cash dispenser And a $10 bill should be ejected by the cash dispenser

Slide 68

Slide 68 text

Scenario: Dispense $50 cash in multiple denominations Given I have $100 in my account And I have a card with the PIN 1234 And I push my card into the machine And I enter 1234 for my PIN And I push the button next to Withdrawal And I push the button next to Checking When I push the button next to $50 Then a $20 bill should be ejected by the cash dispenser And a $20 bill should be ejected by the cash dispenser And a $10 bill should be ejected by the cash dispenser

Slide 69

Slide 69 text

Scenario: Dispense $50 cash in multiple denominations Given I have $100 in my account And I have a card with the PIN 1234 And I push my card into the machine And I enter 1234 for my PIN And I push the button next to Withdrawal And I push the button next to Checking When I push the button next to $50 Then a $20 bill should be ejected by the cash dispenser And a $20 bill should be ejected by the cash dispenser And a $10 bill should be ejected by the cash dispenser

Slide 70

Slide 70 text

Scenario: Dispense $50 cash in multiple denominations Given I have $100 in my account And I have a card with the PIN 1234 And I push my card into the machine And I enter 1234 for my PIN And I push the button next to Withdrawal And I push the button next to Checking When I push the button next to $50 Then a $20 bill should be ejected by the cash dispenser And a $20 bill should be ejected by the cash dispenser And a $10 bill should be ejected by the cash dispenser

Slide 71

Slide 71 text

TDD vs BDD

Slide 72

Slide 72 text

TDD Hard to apply to existing legacy code Inside out Fast execution time “That is wrong” Doing the thing right Technical writer/reader Low case coverage Poor maintainability Easy to apply to existing legacy code Outside in Slow execution time “Something is wrong” Doing the right thing Business writer/reader High case coverage High maintainability BDD

Slide 73

Slide 73 text

TDD or BDD?

Slide 74

Slide 74 text

Final Thoughts

Slide 75

Slide 75 text

No content

Slide 76

Slide 76 text

“It’s a skill! Learn it by using it”

Slide 77

Slide 77 text

Do you release with failing tests? Does it depends?

Slide 78

Slide 78 text

References Test Driven Development: By Example by Kent Beck (2002) Refactoring by Kent Beck and Martin Fowler (1999) Succeeding with Agile by Mike Cohn (2009) Working Effectively with Unit Tests by Jay Fields (2014) The Art of Unit Testing by Roy Osherove (2013) Software Reliability: Principles and Practices by Glenford J. Myers (1976)

Slide 79

Slide 79 text

Thank you!