We have a thousand ways and reasons to test our code. But the sword is double-edged: when reading an unfamiliar test, which of the thousand reasons motivates its presence? When adding a test, which of the thousand possible methods? Clarify the test suite by grouping tests based on the value they bring. article 
slides
_For six months, the small dev team I led tried to build a replacement suite of integration tests. This is one reference I collected in 2014 to inform our effort._
YOUTUBE 9_3RsSvgRd4 Justin Searls, Ancient City Ruby 2014, 45min
# The problem * Why does every refactor break six tests? * Why does the build take 9 hours to run? * Why are people mocking methods on the object they're testing? * Why can't we get anything done anymore? # The story arc We expect a lot from our tests, but mainly _confidence_ or _understanding_ Apply single responsibility to test suites: break up suites around the specific confidence or understanding they bring
# Proposed categories
App level tests: SAFE tests
slide 165
video 895s
Consumption tests
slide 208
video 1185s
Contract tests
slide 251
video 1393s
Discovery testing
slide 294
video 1721s
Adapter testing
slide 380
video 2545s