Open a test at random. Answer:
- Why does it exist?
- What is under test?
- How does it explain edge cases?
- What real things does it replace with fake things?
- What can cause the test to fail?
Unless the answers to those questions are obvious, no one has any clue whether the test is worthwhile. But the murkiness of most test code drives teams to ritualize its upkeep. When tests glow red, generous sacrifices are offered until they turn green again. Over time, faith in the Agile Church of Testing has eroded. Dogma that "thou shalt test" now rings hollow.
Epic tomes have been written on the theory of sound testing, but their detached wisdom rarely survives contact with actual projects. Our understanding becomes muddied as we mangle our tests under the pressure to get things working and features out the door.
This talk will clear the waters by presenting a guideline for testing: a set of sensible defaults to be adopted and tweaked for your own projects. Each rule will be easy-to-follow, promote consistency, and backed by deeper reasoning available to anyone who seeks it. By planting a shared guidepost, everyone on a team or in a community—from novices to experts—will be better-equipped to write tests that can be plainly understood by others.