Can You Read Your Tests? Clean and Useful Android Testing, with JUnit and Spock!
summary
Shows concrete before-and-after tests: plain JUnit examples that silently pass or are brittle, then refactors using Hamcrest/AssertJ and finally Spock where data‑driven tests, expressive failure diffs, spying and stubbing are native. Demonstrates an assertion helper for Rx to eliminate TestSubscriber noise, shows how to split save and read tests to make failures meaningful, and argues for use fakes instead of nested mocks with a small fake that actually works. Expect runnable code snippets and clear tradeoffs rather than high‑level platitudes.
AI-written summary · about
chapters (24)
- 0:00Clean unit testing intro
- 1:12Unreadable test code problems
- 3:01Split tests for clarity
- 4:52One thing per test
- 6:18Meaningless clean tests
- 7:45Simpler test names
- 8:31Complex test bodies restructured
- 9:57Naming for readability
- 10:38Noise in reactive tests
- 12:22Reusable assertion helpers
- 14:09Clear test fixtures
- 15:57Lost test context restored
- 17:47Concise test names
- 18:52Test code smells
- 21:41Test code care matters
- 22:44Break tests to fail
- 23:51Clear failure messages
- 24:13Spock testing intro
- 26:23Spock’s DSL benefits
- 27:48Spock advanced features
- 29:56Spock mocking
- 31:22Spock data-driven tests
- 33:30Spock expressive testing
- 34:15Q&A Spock Espresso
related talks
29mWhy I prefer Spock over JUnit
35mThe Groovy Way of Testing with Spock
46mEasy testing with Spock
01h 12mUnit Tests as a Specification
18mSpeedup unit testing with the Spock framework
49mWhat Mr. Spock would possibly say about modern unit testing
45mWhy Use Spock Instead of JUnit Mockito for Your Java Tests
49mFabulous Tests with Spock and Groovy