Automated CSS Testing - jsday Verona

Transcript

1. Automated
   CSS Testing
   Not Just a Myth
   @jakobmattsson www.jakobm.com
   

   View Slide

2. View Slide

3. View Slide

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

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

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

7. Automated
   CSS Testing
   Not Just a Myth
   

   View Slide

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

   View Slide

9. Declarative programming
   

   View Slide

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

    View Slide

11. View Slide

12. View Slide

13. View Slide

14. Mixins
    Variables
    Reuse
    Nesting
    etc.
    Operations
    

    View Slide

15. Write
    Read
    

    View Slide

16. View Slide

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

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

19. Code quality
    

    View Slide

20. Functional quality—fitness for purpose
    !
    Structural quality—the degree to which the software
    was produced correctly
    

    View Slide

21. Structural quality
    Reliability Maintainability
    Size Efficiency Security
    

    View Slide

22. HOW?
    

    View Slide

23. By writing automated
    TESTS!
    

    View Slide

24. View Slide

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

    View Slide

26. Testing CSS
    

    View Slide

27. Code
    ???
    Visual
    Declarative
    Dilemma
    

    View Slide

28. Let’s try!
    

    View Slide

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

    View Slide

30. View Slide

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

    View Slide

32. View Slide

33. View Slide

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

    View Slide

35. View Slide

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

    View Slide

37. View Slide

38. Screenshots
    Compare visuals before and after change
    Detects impact of change
    

    View Slide

39. View Slide

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

    View Slide

41. View Slide

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

    View Slide

43. View Slide

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

    View Slide

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

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

    View Slide

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

    View Slide

48. View Slide

49. View Slide

50. View Slide

51. WHAT
    is the
    MISSING PIECE?
    

    View Slide

52. Design first
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

56. View Slide

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

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

    View Slide

59. WHAT
    is the
    CORRECT LOOK?
    

    View Slide

60. Red
    1.Create the
    design you want
    

    View Slide

61. View Slide

62. Click
    

    View Slide

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

    View Slide

64. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

68. Design first
    

    View Slide

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

    View Slide

70. View Slide

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

    View Slide

72. Join in!
    

    View Slide

73. Automated
    CSS Testing
    Not Just a Myth
    @jakobmattsson www.jakobm.com
    

    View Slide