Real World Mocking in Swift
summary
Argues OCMock-style runtime patching is impractical in Swift so teams end up writing their own test doubles, demonstrates replacing NSURLSession with a mock and injecting it to assert the request URL, and warns that partial mocks are an anti-pattern because they’re fragile and hard to reason about. Recommends using protocols over subclassing and constructor injection for testability, prefers more value types to avoid mocks, and notes emerging helpers like Kaku plus other framework approaches that generate or simplify mocks.
AI-written summary · about
chapters (16)
- 0:00Intro
- 0:37Asynchronous tests
- 1:16Mock frameworks
- 2:49Mocks take time
- 3:40Why Mocks
- 5:07Why Tests
- 6:47Dependency Injection
- 8:29Why use Dependency Injection
- 10:31stub API
- 11:38time machine
- 13:41Mocking
- 16:15Best Practices
- 17:52NSUserDefaults
- 19:05Time Traveler
- 20:28Controlling Complexity
- 24:14Future of Mocking
related talks
28mMocking with Swift
37mBeyond the Mockery: Why We Should Embrace Testing Without Mocking Frameworks
31mBeyond the Mockery- Why We Should Embrace Testing Without Mocking Frameworks
36mTo Mock or Not to Mock
52mPlease don’t mock me
39mPlease Don't Mock Me
24mMaking Mock Objects More Useful
01h 01m“Mocking Frameworks considered harmful”
