Automated Testing & CSS

Automated Testing & CSS

Test-Driven Development has grown in popularity among the community in the past few years, but we're still lacking the proper tools to provide automation behind our CSS. How do you know a change you made to one small section on a page doesn't break a large section on another page of your site, especially when you support hundreds of devices? These slides look at three options available and show where they succeed and fail.

6823d6d1ee14bd068007bd60ddb6a41a?s=128

Kevin Lamping

October 21, 2013
Tweet

Transcript

  1. 5.
  2. 6.
  3. 7.
  4. 8.
  5. 9.
  6. 10.
  7. 11.

    “Despite CSS being so hard to maintain, it's often the

    part of the FE stack people are least interested in protecting from tech debt.” @necolas
  8. 13.
  9. 14.
  10. 15.

    +

  11. 16.
  12. 17.
  13. 19.
  14. 20.

    Wraith - Recap •Easy, simple set up •Nice site to

    view diffs •Entire screen comparison is bad for dynamic sites •No IE Testing •Need two sites with same content
  15. 21.
  16. 22.
  17. 24.
  18. 25.

    Selector Maps selectors.js module.exports = { "standard paragraph": "section >

    p" }; test.feature Then "standard paragraph" should have "color" of "rgb(68, 68, 68)"
  19. 26.

    selectors.js module.exports = { "standard paragraph": "section > p" };

    test.feature Then "standard paragraph" should have "color" of "rgb(68, 68, 68)" Selector Maps
  20. 32.
  21. 37.
  22. 39.

    Hardy - Recap •Cross-browser coverage •Computed styles & specific shots

    •Site scripting built-in •No nice diff page •More work to set up •Have to repeat CSS •Pay attention to ' and "
  23. 41.

    /* # Buttons Provides extra visual weight and identifies the

    primary action in a set of buttons. ``` <button class="btn primary">Primary</ button> <button class="btn primary :hover">Primary</button> ``` */
  24. 42.
  25. 43.

    StyleDocco - Recap •No login/scripting needed •Allows for pseudo-class testing

    •Content is (mostly) static •Not the actual site