Pro Yearly is on sale from $80 to $50! »

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

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

7dd731d0c97e334d726f740a710904a9?s=128

Jakob Mattsson

November 28, 2013
Tweet

Transcript

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

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

  3. 2 000 000 000 writes/day

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

  5. None
  6. None
  7. None
  8. None
  9. None
  10. None
  11. None
  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.
  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.
  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.
  15. Automated CSS Testing Not Just a Myth

  16. The purpose of this presentation: Raise awareness of existing tools

    Inspire a new workflow
  17. Declarative programming

  18. Declarative programming is a programming paradigm that expresses the logic

    of a computation without describing its control flow.” “
  19. None
  20. None
  21. None
  22. Mixins Variables Reuse Nesting etc. Operations

  23. Write Read

  24. None
  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
  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.” “
  27. Code quality

  28. Functional quality—fitness for purpose Structural quality—the degree to which the

    so!ware was produced correctly
  29. Structural quality Reliability Maintainability Size Efficiency Security

  30. HOW?

  31. By writing automated TESTS!

  32. None
  33. Refactor Red Green 1.Write a test that fails 2.Make the

    code work 3.Eliminate redundancy
  34. Testing CSS

  35. Code ??? Visual Declarative Dilemma

  36. Let’s try!

  37. 1 2 3 4 Two for code Two for visuals

    { { Four approaches
  38. 1

  39. Syntax Checks Checking that the code is actually valid CSS

    Typically performed by an editor, IDE or plugin
  40. None
  41. 2

  42. Styleguides & linting Forces best-practices to be followed Syntactically (where

    to put braces) Semantically (catching common mistakes)
  43. None
  44. Useless without good rules + - Prevents anti-patterns Easy to

    apply Doesn’t test the end result - - +
  45. 3

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

    change
  47. - Pete Hunt

  48. Lots of false positives + - No change can sneak

    by Implementation agnostic Breaks on content changes - - +
  49. 4

  50. Comparing styles in the DOM Sniff the DOM for all

    relevant styles Compare them to some expectation
  51. - Simon Madine

  52. Scenario: Standard paragraph color Given I visit "http://localhost:3000" Then "section

    > p" should have "color" of "rgb(68, 68, 68)"
  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
  54. Style rules != looks + - Resilient to changes Tests

    live on Writing expectations in code - - +
  55. 1 2 3 4 Two for code Two for visuals

    { { Four approaches
  56. None
  57. None
  58. None
  59. WHAT is the MISSING PIECE?

  60. Design first

  61. Refactor Red Green 1.Write a test that fails 2.Make the

    code work 3.Eliminate redundancy
  62. My suggestion: 1. Create the design you want 2. Ensure

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

    and compatibility 3.Eliminate redundancy
  64. 5

  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
  66. We are already running user stories No need for manual

    recording
  67. WHAT is the CORRECT LOOK?

  68. Red 1.Create the design you want

  69. None
  70. Click

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

    compatibility
  72. None
  73. MARK DIFFS as intended or not intended - THE SYSTEM

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

    compatibility 3.Eliminate redundancy Refactor
  75. Design is manual Definition of ”correct” is manual Testing of

    changes is automatic!
  76. Design first

  77. No record step + No convoluted ”design spec” + This

    is make-believe - + Jacking into acceptance tests
  78. None
  79. The purpose of this presentation: Raise awareness of existing tools

    Inspire a new workflow
  80. Join in!

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

    -