Testing the Sad Paths

About Me• 20 years of developing web apps

• Doing TDD/BDD since 2001

• Working with Ruby for the last 8 years

Teespring

• ~ 100,000 lines of code in the web app

• ~ 5,000 Requests / 800 pages per minute

• ~ 7 million shirts sold in 2014

• Real people making real money

Teespring• We try to TDD as much as possible

• We do serious code review

• We use a CI Server to test pull requests

• We also do manual QA before deploying

• (And, one other thing - we’re hiring!)

Some Tools We Use• Ruby/Rails/(and JS) Stack

• Rspec

• Capybara

• Webmock/VCR

• SimpleCov

What Do We Test?

The Sad Path

The Sad Path

• Happy paths are usually tested and built first

• Sad paths can be overlooked

• Many users will find the sad path

Your QA teamThey often deal with the sad paths while manual testing

Error Handling

• Defensive Coding

• Handling expected problems

• Logging/Tracking error information

• “Exceptional Ruby” covers this topic really well

Failure Modes

Three Types of Failure

• User does something wrong

• System does something wrong

• Transient - overloaded, slow, unavailable, etc.

Testing for User Errors

Things to Consider• What constitutes valid vs. invalid input?

• Where can invalid input possibly enter the system?

• How do you deal with invalid input in other parts if the system?

Logic Errors

Things to Consider• Almost any part of your system can fail.

• Handling vs. preventing failure

• Nil is a tenacious enemy

• How will you recover from errors?

Transient Errors

Things to Consider• Is it even worth retrying?

• Retrying forever is probably a bad thing.

• How do you communicate to users to come back later?

• How do you isolate the failure to a small area?

Questions?

Links• http://rspec.info/

• https://cukes.info/

• https://github.com/jnicklas/capybara

• https://github.com/bblimke/webmock

• https://github.com/vcr/vcr

• https://github.com/colszowka/simplecov

• http://exceptionalruby.com/