Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Automated testing

Automated testing

They why, what and how of automated testing for a mixed technical and non-technical audience.

Marc Tamlyn

July 12, 2013
Tweet

More Decks by Marc Tamlyn

Other Decks in Programming

Transcript

  1. What is it? • Unit tests • Integration tests •

    Functional/acceptance tests • Visual tests • Regression tests
  2. What is it not? • A complete replacement for QA,

    a useful tool for doing QA • For content
  3. Unit tests • Test small specific pieces of functionality •

    Cover as many cases as possible • (Should be) quick and easy • Fragile but isolated • Mock out other layers • Coverage
  4. Integration tests • Work across multiple layers of the program

    • Ensure all the individual pieces fit together • Simulate real requests • Test only “normal” things • Should break less often
  5. Functional or Acceptance tests • Test the whole system •

    Test user stories • “Open up browser, go to home page, click on login link, fill in correct information, redirects to profile page, click on forum navigation, make a post, post appears on page...”
  6. Functional or Acceptance tests • SLOW, and harder to write

    • More likely part of the QA process than the development process • Immensely useful for front end logic
  7. Visual tests • Does this page look like this screenshot?

    • Cross browser • Needs research...
  8. Regression tests • “AAAA this is broken we must fix

    it now” • “I’ll write a test for it” • A bug is not a bug, it’s a missing test • Makes sure the bug doesn’t come back
  9. Regression tests • Could be any one of the other

    kinds of test • Never get written if the project didn’t have tests to start with
  10. Continuous integration • Runs test suite against changes and pull

    requests • Warns us if someone breaks things • Runs in a production-like setting
  11. Test driven development • Write the tests first • Add

    code afterwards • (Refactor) • Check tests still pass • Repeat
  12. Test driven development • Feels slower to start with •

    More reliable than “refreshing the page to see if it worked” • Requires good tools • Saves time (and face) in the long run