Slide 1

Slide 1 text

Jakob Mattsson @jakobmattsson Developer • Entrepreneur • Crazy person

Slide 2

Slide 2 text

Lean Startups Agile XP Pairing TDD etc...

Slide 3

Slide 3 text

2 000 000 000 writes/day

Slide 4

Slide 4 text

Quick and easy customer feedback. touch-and-tell.se

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

Wikipedia on ”Melodic death metal” Melodic death metal is an extreme subgenre of heavy metal music. The Swedish death metal scene did much to popularize the style, which soon centered in the "Gothenburg metal" scene in Gothenburg, Sweden.

Slide 13

Slide 13 text

Wikipedia on ”Melodic death metal” Melodic death metal is an extreme subgenre of heavy metal music. The Swedish death metal scene did much to popularize the style, which soon centered in the "Gothenburg metal" scene in Gothenburg, Sweden.

Slide 14

Slide 14 text

Wikipedia on ”Melodic death metal” Melodic death metal is an extreme subgenre of heavy metal music. The Swedish death metal scene did much to popularize the style, which soon centered in the "Gothenburg metal" scene in Gothenburg, Sweden.

Slide 15

Slide 15 text

Automated CSS Testing Not Just a Myth

Slide 16

Slide 16 text

The purpose of this presentation: Raise awareness of existing tools Inspire a new workflow

Slide 17

Slide 17 text

Declarative programming

Slide 18

Slide 18 text

Declarative programming is a programming paradigm that expresses the logic of a computation without describing its control flow.” “

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

Mixins Variables Reuse Nesting etc. Operations

Slide 23

Slide 23 text

Write Read

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

New styles are added instead of reuse Unused styles are not removed No overview of how different styles interact Form factors, adaptiveness, responsiveness The true ”write-only” language

Slide 26

Slide 26 text

In computer humor, a write-only language is a programming language with syntax (or semantics) sufficiently dense and bizarre that any routine of significant size is too difficult to understand by other programmers and cannot be safely edited.” “

Slide 27

Slide 27 text

Code quality

Slide 28

Slide 28 text

Functional quality—fitness for purpose Structural quality—the degree to which the so!ware was produced correctly

Slide 29

Slide 29 text

Structural quality Reliability Maintainability Size Efficiency Security

Slide 30

Slide 30 text

HOW?

Slide 31

Slide 31 text

By writing automated TESTS!

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

Refactor Red Green 1.Write a test that fails 2.Make the code work 3.Eliminate redundancy

Slide 34

Slide 34 text

Testing CSS

Slide 35

Slide 35 text

Code ??? Visual Declarative Dilemma

Slide 36

Slide 36 text

Let’s try!

Slide 37

Slide 37 text

1 2 3 4 Two for code Two for visuals { { Four approaches

Slide 38

Slide 38 text

1

Slide 39

Slide 39 text

Syntax Checks Checking that the code is actually valid CSS Typically performed by an editor, IDE or plugin

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

2

Slide 42

Slide 42 text

Styleguides & linting Forces best-practices to be followed Syntactically (where to put braces) Semantically (catching common mistakes)

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

Useless without good rules + - Prevents anti-patterns Easy to apply Doesn’t test the end result - - +

Slide 45

Slide 45 text

3

Slide 46

Slide 46 text

Screenshots Compare visuals before and a"er change Detects impact of change

Slide 47

Slide 47 text

- Pete Hunt

Slide 48

Slide 48 text

Lots of false positives + - No change can sneak by Implementation agnostic Breaks on content changes - - +

Slide 49

Slide 49 text

4

Slide 50

Slide 50 text

Comparing styles in the DOM Sniff the DOM for all relevant styles Compare them to some expectation

Slide 51

Slide 51 text

- Simon Madine

Slide 52

Slide 52 text

Scenario: Standard paragraph color Given I visit "http://localhost:3000" Then "section > p" should have "color" of "rgb(68, 68, 68)"

Slide 53

Slide 53 text

Scenario: Filter the list of audio books Given some audiobooks in the collection When I visit the list of audiobooks And I search for "cor" Then I only see matching titles When I remove the filter Then I see all audiobooks again

Slide 54

Slide 54 text

Style rules != looks + - Resilient to changes Tests live on Writing expectations in code - - +

Slide 55

Slide 55 text

1 2 3 4 Two for code Two for visuals { { Four approaches

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

WHAT is the MISSING PIECE?

Slide 60

Slide 60 text

Design first

Slide 61

Slide 61 text

Refactor Red Green 1.Write a test that fails 2.Make the code work 3.Eliminate redundancy

Slide 62

Slide 62 text

My suggestion: 1. Create the design you want 2. Ensure consistency and compatibility 3. Eliminate redundancy

Slide 63

Slide 63 text

Refactor Red Green 1.Create the design you want 2.Ensure consistency and compatibility 3.Eliminate redundancy

Slide 64

Slide 64 text

5

Slide 65

Slide 65 text

Scenario: Filter the list of audio books Given some audiobooks in the collection When I visit the list of audiobooks And I search for "cor" Then I only see matching titles When I remove the filter Then I see all audiobooks again

Slide 66

Slide 66 text

We are already running user stories No need for manual recording

Slide 67

Slide 67 text

WHAT is the CORRECT LOOK?

Slide 68

Slide 68 text

Red 1.Create the design you want

Slide 69

Slide 69 text

No content

Slide 70

Slide 70 text

Click

Slide 71

Slide 71 text

Red Green 1.Create the design you want 2.Ensure consistency and compatibility

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

MARK DIFFS as intended or not intended - THE SYSTEM REMEMBERS

Slide 74

Slide 74 text

Red Green 1.Create the design you want 2.Ensure consistency and compatibility 3.Eliminate redundancy Refactor

Slide 75

Slide 75 text

Design is manual Definition of ”correct” is manual Testing of changes is automatic!

Slide 76

Slide 76 text

Design first

Slide 77

Slide 77 text

No record step + No convoluted ”design spec” + This is make-believe - + Jacking into acceptance tests

Slide 78

Slide 78 text

No content

Slide 79

Slide 79 text

The purpose of this presentation: Raise awareness of existing tools Inspire a new workflow

Slide 80

Slide 80 text

Join in!

Slide 81

Slide 81 text

Automated CSS Testing Not Just a Myth @jakobmattsson bit.ly/jsconf-css + -