Automated CSS Testing - Not Just a Myth (JSConf.Asia)

Transcript

1. Jakob Mattsson
   @jakobmattsson
   Developer • Entrepreneur • Crazy person
   

   View Slide

2. Lean
   Startups
   Agile
   XP
   Pairing
   TDD
   etc...
   

   View Slide

3. 2 000 000 000 writes/day
   

   View Slide

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

   View Slide

5. View Slide

6. View Slide

7. View Slide

8. View Slide

9. View Slide

10. View Slide

11. View Slide

12. 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.
    

    View Slide

13. 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.
    

    View Slide

14. 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.
    

    View Slide

15. Automated
    CSS Testing
    Not Just a Myth
    

    View Slide

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

    View Slide

17. Declarative programming
    

    View Slide

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

    View Slide

19. View Slide

20. View Slide

21. View Slide

22. Mixins
    Variables
    Reuse
    Nesting
    etc.
    Operations
    

    View Slide

23. Write
    Read
    

    View Slide

24. View Slide

25. 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
    

    View Slide

26. 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.”
    “
    

    View Slide

27. Code quality
    

    View Slide

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

    View Slide

29. Structural quality
    Reliability Maintainability
    Size Efficiency Security
    

    View Slide

30. HOW?
    

    View Slide

31. By writing automated
    TESTS!
    

    View Slide

32. View Slide

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

    View Slide

34. Testing CSS
    

    View Slide

35. Code
    ???
    Visual
    Declarative
    Dilemma
    

    View Slide

36. Let’s try!
    

    View Slide

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

    View Slide

38. View Slide

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

    View Slide

40. View Slide

41. View Slide

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

    View Slide

43. View Slide

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

    View Slide

45. View Slide

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

    View Slide

47. - Pete Hunt
    

    View Slide

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

    View Slide

49. View Slide

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

    View Slide

51. - Simon Madine
    

    View Slide

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

    View Slide

53. 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
    

    View Slide

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

    View Slide

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

    View Slide

56. View Slide

57. View Slide

58. View Slide

59. WHAT
    is the
    MISSING PIECE?
    

    View Slide

60. Design first
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

64. View Slide

65. 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
    

    View Slide

66. We are already running user stories
    No need for manual recording
    

    View Slide

67. WHAT
    is the
    CORRECT LOOK?
    

    View Slide

68. Red
    1.Create the
    design you want
    

    View Slide

69. View Slide

70. Click
    

    View Slide

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

    View Slide

72. View Slide

73. MARK DIFFS
    as intended or not intended -
    THE SYSTEM REMEMBERS
    

    View Slide

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

    View Slide

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

    View Slide

76. Design first
    

    View Slide

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

    View Slide

78. View Slide

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

    View Slide

80. Join in!
    

    View Slide

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

    View Slide