Agile JavaScript Testing
•19 likes•6,243 views
Report
Share
Download to read offline
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.
More Related Content
What's hot
What's hot(20)
Viewers also liked
Viewers also liked(20)
![[C5]deview 2012 nodejs](https://cdn.slidesharecdn.com/ss_thumbnails/c5deview2012nodejs-120920013859-phpapp01-thumbnail.jpg?width=768&fit=bounds)
Similar to Agile JavaScript Testing
Similar to Agile JavaScript Testing(20)
Recently uploaded
Recently uploaded(20)
Agile JavaScript Testing
- 1. Agile JavaScript Testing Making the web a better place
- 4. For better quality And less bugs
- 5. It Goes like this:
- 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. 2. Write a test Test what the code is supposed to do
- 8. 3. Run the test It will fail.
- 9. 4. Write the code Make the test pass
- 10. Repeat...
- 11. Confused?
- 12. “Don’t tests come after?”
- 13. Terminology issues... “tests”, “assertions”, etc...
- 14. Get the words right (it’s easier to think)
- 15. Behavior Driven Development same thing, better terminology
- 16. In BDD you write “specs” to describe “behavior” you describe what you “expect” to occur
- 18. Behavior Driven Development With Screw.Unit, a BDD framework for JS http://github.com/nkallen/screw-unit
- 19. Oversimplified Example We need a method of doubling a number
- 20. First in plain text describe doubleIt - it returns twice the number passed to it
- 22. What do we expect?
- 23. Now run the spec
- 24. Define doubleIt
- 25. Run the spec again
- 26. You want 4?! Done!
- 27. Run the spec again
- 28. A couple more expectations
- 29. Run the spec again
- 31. Run the spec again
- 32. One expectation per spec Recommended, not always necessary. Just be pragmatic.
- 34. Run the spec again
- 35. Before / After Setup and teardown
- 36. Higher level - UI interactions
- 37. Testing the DOM Verify JS is doing what we expect to the HTMLs
- 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. Testing the DOM In your specs, you can interact with it:
- 40. Always more to explore... Mocking and Stubbing - using the Smoke library Testing / simulating browser events Testing / mocking ajax requests and callbacks
- 41. Integrate with your workflow An example using Blue Ridge for Ruby on Rails
- 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. http://github.com/relevance/blue-ridge
- 43. Always be testing Run your JS tests at the same time as your other tests! Example...
- 44. A universe of browsers each with its own “features” (bugs)
- 45. JS Test Driver Parallel cross-browser testing via command line
- 46. JS Test Driver http://code.google.com/p/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. Future / Other Test Swarm: Distributed Continous Integration for JS http://testswarm.com JSpec: An alternative BDD framework for JS http://visionmedia.github.com/jspec