High Cost Tests and High Value Tests
summary
An inventory management Rails app gets tested with Capybara system tests, mid-level workflow/service objects and fast unit specs, and the numbers matter: about 180 specs total, system tests run 0.5–3s each, 22 system specs take ~13s so 12% of specs cost 75% of runtime, and the slowest four tests are 40% of run time. Edge cases get unit tests that run in milliseconds, factory_bot associations and end-to-end tests cause most long-term cost, and faster focused tests make failures easy to locate.
AI-written summary · about
chapters (36)
- 0:00Start
- 2:27I could just write integration tests
- 3:38I'm making a decision
- 3:53What does worth it mean?
- 4:50How can you measure cost and value?
- 7:00How do tests cost time?
- 7:24runs A lot
- 8:07fixed
- 8:30How do tests save time?
- 8:57Running the test is faster than manual testing
- 10:03Bugs Faster
- 11:17Forever
- 12:20Strategy Tactics
- 17:36System tests are 12% of the code and 75% of the output
- 18:48Another project
- 20:15Balance 1 time spent
- 20:55down
- 21:24Short term cost is not related to test type
- 22:23runtime failure
- 22:38complexity
- 24:00No individual test causes a slow suite
- 28:27Failure paths: Bad Input
- 28:54System Test Workflow Test Unit test
- 32:09A lot of Copy/Paste
- 32:46Logic change is far away from method under test
- 33:05Capybara is not a unit test framework
- 33:58TDD is Dead
- 34:29Unit tests cost too much to write
- 35:06True if framework doesn't handle tests
- 35:16Unit tests force hard to understand designs
- 36:12Really good legacy code strategy
- 36:26Strategies
- 36:42fail?
- 38:09Create the minimum amount of objects needed to trigger the failure
- 38:32Use multiple test failures as an opportunity
- 39:09Use integration tests to save development time
