Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile JavaScript Testing

Cover the advantages of test driven development, the reasons for pushing it all the way to the browser level, and then explore the options for testing JavaScript, look at some examples, and then integrate the tests into our existing development workflow.

  • Login to see the comments

Agile JavaScript Testing

  1. 1. Agile JavaScript Testing Making the web a better place
  2. 2. What? TDD is...
  3. 3. A Design Method
  4. 4. For better quality And less bugs
  5. 5. It Goes like this:
  6. 6. 1. Think: What is this code supposed to do? How am I going to interact with it? What would be the simplest, clearest API?
  7. 7. 2. Write a test Test what the code is supposed to do
  8. 8. 3. Run the test It will fail.
  9. 9. 4. Write the code Make the test pass
  10. 10. Repeat...
  11. 11. Confused?
  12. 12. “Don’t tests come after?”
  13. 13. Terminology issues... “tests”, “assertions”, etc...
  14. 14. Get the words right (it’s easier to think)
  15. 15. Behavior Driven Development same thing, better terminology
  16. 16. In BDD you write “specs” to describe “behavior” you describe what you “expect” to occur
  17. 17. It’s more like...
  18. 18. Behavior Driven Development With Screw.Unit, a BDD framework for JS
  19. 19. Oversimplified Example We need a method of doubling a number
  20. 20. First in plain text describe doubleIt - it returns twice the number passed to it
  21. 21. Now with Screw.Unit
  22. 22. What do we expect?
  23. 23. Now run the spec
  24. 24. Define doubleIt
  25. 25. Run the spec again
  26. 26. You want 4?! Done!
  27. 27. Run the spec again
  28. 28. A couple more expectations
  29. 29. Run the spec again
  30. 30. Refactor the code
  31. 31. Run the spec again
  32. 32. One expectation per spec Recommended, not always necessary. Just be pragmatic.
  33. 33. Refactor the specs
  34. 34. Run the spec again
  35. 35. Before / After Setup and teardown
  36. 36. Higher level - UI interactions
  37. 37. Testing the DOM Verify JS is doing what we expect to the HTMLs
  38. 38. Testing the DOM In suite.html (container file), have a special DOM node: In a before block, set it to it’s default state:
  39. 39. Testing the DOM In your specs, you can interact with it:
  40. 40. Always more to explore... Mocking and Stubbing - using the Smoke library Testing / simulating browser events Testing / mocking ajax requests and callbacks
  41. 41. Integrate with your workflow An example using Blue Ridge for Ruby on Rails
  42. 42. Blue Ridge A JavaScript Testing plugin for Rails Run JavaScript tests via the command-line, with a head-less browser environment Uses Rhino - a Java based JavaScript interpreter And env.js - an implementation of the DOM in pure JavaScript (thanks John Resig!) Screw.Unit and Smoke built in! Plus generators.
  43. 43. Always be testing Run your JS tests at the same time as your other tests! Example...
  44. 44. A universe of browsers each with its own “features” (bugs)
  45. 45. JS Test Driver Parallel cross-browser testing via command line
  46. 46. JS Test Driver Launch the server Capture one or more browsers Write tests and code Run your tests Bonus: Continously run tests, whenever files change
  47. 47. Future / Other Test Swarm: Distributed Continous Integration for JS JSpec: An alternative BDD framework for JS
  48. 48. Thanks! Scott Becker