Automated CSS Testing: Not just a myth

7dd731d0c97e334d726f740a710904a9?s=47 Jakob Mattsson
September 10, 2013

Automated CSS Testing: Not just a myth

Presented at MMWCON 2013, UCLA, Los Angeles

7dd731d0c97e334d726f740a710904a9?s=128

Jakob Mattsson

September 10, 2013
Tweet

Transcript

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

  2. 2 000 000 000 writes/day!

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

  4. None
  5. None
  6. None
  7. None
  8. None
  9. Automated CSS Testing Not Just a Myth

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

    Inspire a new workflow Get your help
  11. The purpose of this presentation: Raise awareness of existing tools

    Inspire a new workflow Get your help
  12. The purpose of this presentation: Raise awareness of existing tools

    Inspire a new workflow Get your help
  13. The purpose of this presentation: Raise awareness of existing tools

    Inspire a new workflow Get your help
  14. Declarative programming

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

    of a computation without describing its control flow.” “
  16. Do not try it @127.0.0.1

  17. None
  18. None
  19. None
  20. Mixins Variables Reuse Nesting etc. Operations

  21. None
  22. Write Read

  23. None
  24. None
  25. New styles are added instead of reuse

  26. New styles are added instead of reuse Unused styles are

    not removed
  27. New styles are added instead of reuse Unused styles are

    not removed No overview of how different styles interact
  28. New styles are added instead of reuse Unused styles are

    not removed No overview of how different styles interact Form factors, adaptiveness, responsiveness
  29. 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
  30. 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.” “
  31. Code quality

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

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

  34. HOW?

  35. By writing automated TESTS!

  36. None
  37. Refactor Red Green 1.Write a test that fails 2.Make the

    code work 3.Eliminate redundancy
  38. Testing CSS

  39. Code ??? Profit Declarative Dilemma

  40. Let’s try!

  41. 1 2 3 4 Two for code Two for result

    { { Four approaches
  42. 1

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

    Typically performed by an editor, IDE or plugin
  44. 2

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

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

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

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

    change
  50. None
  51. Lots of false positives + - No change can sneak

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

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

    relevant styles Compare them to some expectation
  54. None
  55. Scenario: Standard paragraph color Given I visit "http://localhost:3000" Then "section

    > p" should have "color" of "rgb(68, 68, 68)"
  56. Style rules != looks + - Resilient to changes Tests

    live on Writing expectations in code - - +
  57. None
  58. None
  59. None
  60. WHAT is the MISSING PIECE?

  61. Design first

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

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

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

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

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

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

    and compatibility 3.Eliminate redundancy
  68. None
  69. Click

  70. None
  71. Examples

  72. ul:last-child { color: red; } Won’t work in IE8. Will

    be caught when test runs there. #footer { width: calc(100% - 3em); } Won’t work on Android or Safari < 6 Unsupported CSS-style used
  73. CSS-inconsistency across browsers <html> <head> <style type="text/css"> h1, h2, h3,

    h4, h5, h6, a { display: block; } ul { list-style-position: inside; } </style> </head> <body> <ul> <li> <h3>Foobar</h3> </li> <ul> </body> </html> Chrome Firefox
  74. <html> <head> <style type="text/css"> body { margin:0; padding:0; } div

    { margin:0; padding:10; } </style> </head> <body> <div>Foobar</div> </body> </html> <html> <head> <style type="text/css"> body { margin:10; padding:0; } div { margin:0; padding:0; } </style> </head> <body> <div>Foobar</div> </body> </html> Detecting equivalent styles This change does not trigger an error; the rendered result is the same, even though styles differ.
  75. Now what?

  76. None
  77. Join in!

  78. Automated CSS Testing Not Just a Myth @jakobmattsson • jakob@leanmachine.se

    github.com/leanmachine/testbit
  79. Automated CSS Testing Not Just a Myth @jakobmattsson • jakob@leanmachine.se

    github.com/leanmachine/testbit bit.ly/jakob-mmwcon + -