Slide 1

Slide 1 text

Application Quality What is it? How to create it? How to maintain it? Why should I care? @ KaunasPHP v.7

Slide 2

Slide 2 text

Who are we? Artūras Šmorgun http://asm.lt @asarturas Marijus Kilmanas http://about.me/mkilmanas @mkilmanas

Slide 3

Slide 3 text

Why are we here? • Because quality matters; • Because we care about the reputation of our craft and the craftsmen; • Because there is a way to sleep calm at night.

Slide 4

Slide 4 text

Software Quality? What is quality?

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

What if we ignore quality? External Quality

Slide 16

Slide 16 text

What if we ignore quality? Internal Quality

Slide 17

Slide 17 text

“But it slows us down”

Slide 18

Slide 18 text

“But it slows us down”

Slide 19

Slide 19 text

Are we responsible? • We are professionals • quality is expected • We are craftsmen • we should do our job to the best • Quality = recommendation • trust of customers

Slide 20

Slide 20 text

Maintaining quality • Continuos integration • Continuos refactoring

Slide 21

Slide 21 text

Why we need tests? • Refactoring without tests is... • Pain • Insane • Suicide • Refucktoring ...

Slide 22

Slide 22 text

External Quality

Slide 23

Slide 23 text

Cycles of life External Internal

Slide 24

Slide 24 text

Let’s speak Gherkin!

Slide 25

Slide 25 text

Let’s speak Gherkin! In order to cooperate As developers / agency We need to have a common language • States the business value; • Defines the beneficiary; • Gives an idea of what is needed to achieve value.

Slide 26

Slide 26 text

Scenario: Customer understands Gherkin Given I produce feature specification When customer reads them Then they should understand what we agree upon • Lists assumptions and preconditions; • Defines what action triggers the behavior; • Tells how to verify if behavior was correct; Let’s speak Gherkin!

Slide 27

Slide 27 text

Scenario: Gherkin can be tested Given customer confirmed the feature When when we implement them Then we should be able to verify they conform to the agreed requirements • Defines exactly how much functionality is needed; • Automates acceptance criteria; • Guides development process; Let’s speak Gherkin!

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

Example feature file

Slide 30

Slide 30 text

Step code: Given

Slide 31

Slide 31 text

Step code: When

Slide 32

Slide 32 text

Step code: When

Slide 33

Slide 33 text

Step code: Then

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

Mink Webdrivers • Goutte (headless) • Selenium (full browser) • Selenium2 (modern selenium) • Sahi (selenium on JS) • Zombie.js (headless JS browser) • Phantom.js (headless JS browser)

Slide 36

Slide 36 text

Sessions • Used within a single scenario; • Represents state of the browser; • Page object is a sub-property; • Allows different browser for separate scenarios.

Slide 37

Slide 37 text

Common pitfalls • Too technical; • Too enterprise’y; • Coupled with dataset / environment.

Slide 38

Slide 38 text

Internal Quality

Slide 39

Slide 39 text

Cycles of life External Internal

Slide 40

Slide 40 text

Motivation • Wo do make mistakes; • Integration testing is expensive; • Testing afterwards is boring; • “Test last” encourages to skip it; • We want to code, not to debug.

Slide 41

Slide 41 text

TDD Telecommunication Device for the Deaf Test Driven Development

Slide 42

Slide 42 text

What TDD is not: • It’s not about verifying; • It’s not about “waterfall”; • It’s not for fast hacks.

Slide 43

Slide 43 text

What TDD is: • It’s about communication; • It’s about being agile; • It’s for long term relationships.

Slide 44

Slide 44 text

3 rules of TDD: • Do not write production code unless there is failing test; • Do not write more test than it is sufficient to fail; • Do not write more production code than it is sufficient to pass failing test.

Slide 45

Slide 45 text

TDD cycle

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

Problems? • A lot of scaffolding have to be done in order to write test; • Mocking is expensive (time = money); • Misleading terminology.

Slide 48

Slide 48 text

TDD v2.0 TDD Done Right

Slide 49

Slide 49 text

Spec BDD It’s not about verification, it’s about emerging design.

Slide 50

Slide 50 text

TDD ⇾ BDD • Test Case ⇾ Specification • Test ⇾ Example • Assertion ⇾ Expectation

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

PhpSpec • Easy to use: • does boring stuff for you; • mocking & stubbing is very easy; • TDD cycle oriented; • Behavior oriented: • encourages specification by example.

Slide 53

Slide 53 text

Installation

Slide 54

Slide 54 text

composer.json { ”require-dev”: { ”phpspec/phpspec”: ”2.0.*@dev” }, ”config”: { ”bin-dir”: ”bin” }, ”autoload”: { ”psr-0”: {””: “src”}} }

Slide 55

Slide 55 text

Run! $ curl http://getcomposer.org/installer | php $ php composer.phar install --dev

Slide 56

Slide 56 text

Usage

Slide 57

Slide 57 text

Generate Spec RED

Slide 58

Slide 58 text

Edit spec RED

Slide 59

Slide 59 text

Run specs RED

Slide 60

Slide 60 text

Run specs RED

Slide 61

Slide 61 text

Run specs RED

Slide 62

Slide 62 text

Edit code GREEN

Slide 63

Slide 63 text

Edit code GREEN

Slide 64

Slide 64 text

Run specs REFACTOR

Slide 65

Slide 65 text

Matchers

Slide 66

Slide 66 text

Identity (===) shouldBe() shouldReturn() shouldBeEqualTo() shouldEqual()

Slide 67

Slide 67 text

Identity (===) Expectation: Will match:

Slide 68

Slide 68 text

Comparison (==) shouldBeLike()

Slide 69

Slide 69 text

Comparison (==) Expectation: Will match:

Slide 70

Slide 70 text

Throw shouldThrow()->during()

Slide 71

Slide 71 text

Throw Expectation: Will match:

Slide 72

Slide 72 text

Type beAnInstanceOf() returnAnInstanceOf() haveType()

Slide 73

Slide 73 text

Type Expectation: Will match:

Slide 74

Slide 74 text

Object State has -> have is -> be

Slide 75

Slide 75 text

has -> have Expectation: Will match:

Slide 76

Slide 76 text

is -> be Expectation: Will match:

Slide 77

Slide 77 text

Inline Matchers you can also define your own matchers

Slide 78

Slide 78 text

Let & Let go

Slide 79

Slide 79 text

->beConstructedWith() Spec: Code:

Slide 80

Slide 80 text

Doubles

Slide 81

Slide 81 text

Doubles • Dummy • Fake • Mock • Stub • Spy ←Control indirect output ←Messaging ←No behavior

Slide 82

Slide 82 text

No behavior

Slide 83

Slide 83 text

Messaging

Slide 84

Slide 84 text

Indirect output

Slide 85

Slide 85 text

Questions?

Slide 86

Slide 86 text

“Live” Demo

Slide 87

Slide 87 text

“Live” Demo • Code: • https://github.com/asarturas/bdd- demo-petition-website • Video (without commentaries, sorry): • https://www.dropbox.com/sh/ bmru6po6khybv0p/QaLfyLL8-h#/

Slide 88

Slide 88 text

Recap

Slide 89

Slide 89 text

We are professionals! Quality is expected

Slide 90

Slide 90 text

Quality Internal & External

Slide 91

Slide 91 text

Create and maintain External Internal

Slide 92

Slide 92 text

Inviqa provides training • on Professional PHP and OOD • on Agile development • on collaborative BDD approach • on full stack BDD in use • on git & git flow • and many more

Slide 93

Slide 93 text

We are looking for team mates! Senior Software Engineers, passionate about their job. (but we mean it!) Kaunas, London, Liverpool, Sheffield, Manchester, Edinburgh, Leeds.

Slide 94

Slide 94 text

Thank you!