Choosing an effective testing structure
summary
Advocates writing tests that fail with helpful messages, puts expected values on the right, and uses Machete to match only relevant fields; prefers async tests to use more cores and surface race conditions. Recommends bypass plus injecting test URLs via process_tree (works in ~90–95% of call patterns) instead of mutating application env, and running fast with mix test watch. Suggests aiming for ~80% coverage, avoiding meck-style module replacement, and using StreamData, parameterized tests, and name for specific needs.
AI-written summary · about
chapters (21)
- 0:00Effective testing introduction
- 1:14Writing tests to fail
- 3:22Placing expected values
- 4:46Machete for assertions
- 5:47Tests asynchronously
- 6:27Mocking HTTP with Bypass
- 8:13Global state with ProcessTree
- 9:59Verify tests by changing code
- 10:39Avoid factory value dependencies
- 12:04Conditional factory setups
- 13:07Tests with Given-When-Then
- 14:09Efficient tests with Mix Test Watch
- 14:50Visualize test execution with XUnit Span
- 15:31Run single tests by name
- 16:33Avoid 100% coverage obsession
- 17:15Group assertions in one test
- 17:56Avoid Meck-based mocking
- 18:16Parameterized tests with tables
- 19:18Snapshot testing with Neam
- 20:41Property-based testing with StreamData
- 21:23Q&A
