Testing in Swift: The Pursuit of Happiness

Transcript

1. Testing in Swift The Pursuit of Happiness
2. Luis Recuenco @luisrecuenco
4. Previously, on NSCoder...
5. iOS Architecture A State Container based approach The Movie
7. Lwift
8. Testing
9. Testing in Swift The Pursuit of Happiness
12. Controversial topic
14. Strong opinions
15. Thoughtful Opinions Held Loosely
17. Back to the basics
18. Three basic questions
19. Three basic questions 1. What's the purpose of testing?
20. Three basic questions 1. What's the purpose of testing? 2. What makes code difficult to test?
21. Three basic questions 1. What's the purpose of testing? 2. What makes code difficult to test? 3. What to test?
22. 1. What's the purpose of testing?
23. What's the purpose of testing? • Proving correct behavior
24. What's the purpose of testing? • Proving correct behavior • Changeability
25. A good design is easier to change than a bad design — Dave Thomas
26. What's the purpose of testing? • Proving correct behavior • Changeability • Refactoring with confidence
27. What's the purpose of testing? • Proving correct behavior • Changeability • Refactoring with confidence • Reduce bugs
28. What's the purpose of testing? • Proving correct behavior • Changeability • Refactoring with confidence • Reduce bugs • Documentation
29. What's the purpose of testing? • Proving correct behavior • Changeability • Refactoring with confidence • Reduce bugs • Documentation • Application design when doing tests first
30. The true purpose
31. The true purpose Reduce costs
32. 2. What makes code difficult to test?
33. func apply(to job: Job) { guard User.current.canApply else { return } API.shared.apply(to: job) }
34. Effects & Coffects
35. Effects Observable change in the external world
36. Effects Hidden outputs
37. Coeffects The environment, the context
38. Coeffects Hidden inputs
39. func apply(to job: Job) { guard User.current.canApply else { return } API.shared.apply(to: job) }
40. func apply(to job: Job) { guard User.current.canApply else { return } API.shared.apply(to: job) }
41. Controlling coeffects
42. Controlling coeffects Inject environment
43. func apply( to job: Job, api: API, currentUser: User, ) { guard currentUser.canApply else { return } api.apply(to: job) }
44. Controlling effects
45. Mocking
46. Effects as values
47. 3. What to test?
48. OOP is all about messages
50. Three types of messages • Incoming • Outgoing • Sent to self
51. Queries and commands
52. Query Returns a value without performing side effects
53. Command Returns nothing and performs side effects
54. class ViewModel { init(api: API) { ... } var state: State func fetchData() { guard api.canFetchData else { return } api.fetchData() } func numberOfItems() -> Int { ... } }
55. class ViewModel { init(api: API) { ... } var state: State func fetchData() { // Incoming command guard api.canFetchData else { return } api.fetchData() } func numberOfItems() -> Int { ... } }
56. class ViewModel { init(api: API) { ... } var state: State func fetchData() {} guard api.canFetchData else { return } api.fetchData() } func numberOfItems() -> Int { ... } // Incoming query }
57. class ViewModel { init(api: API) { ... } var state: State { ... } func fetchData() { guard api.canFetchData else { return } api.fetchData() // Outgoing command } func numberOfItems() -> Int { ... } }
58. class ViewModel { init(api: API) { ... } var state: State { ... } func fetchData() { guard api.canFetchData else { return } // Outgoing query api.fetchData() } func numberOfItems() -> Int { ... } }
59. class ViewModel { init(api: API) { ... } var state: State { ... } // Side effect func fetchData() { guard api.canFetchData else { return } // Outgoing query api.fetchData() } func numberOfItems() -> Int { ... } }
60. Testing incoming command // Arrange let mockedApi = API(mockedData) let sut = ViewModel(api: mockedAPI) // Act sut.fetchData() // Assert assert(sut.state, expectedState) // Assert public side effect
61. Testing outgoing command // Arrange let mockedApi = API(mockedData) expect(mockedApi, #selector(fetchData)) let sut = ViewModel(api: mockedAPI) // Act sut.fetchData() // Assert mockedData.verify() // Verify mock
62. Testing incoming query // Arrange let sut = ViewModel(state: State(items: 5)) // Assert assert(sut.numberOfItems, 5) // Assert return value
63. Incoming Outgoing Sent to self Query assert return value - - Command assert side effect via public api mocking -
64. Two problems
65. Two problems 1. Arrange step: controlling coeffects
66. Two problems 1. Arrange step: controlling coeffects 2. Mocking: controlling effects
67. Cumbersome Arrange
68. Dependency Injection
69. ViewController | ViewModel | Service | APIClient
70. Test ViewController in isolation
71. class MockAPIClient: APIClient { override func fetchData<T>(_ callback: (T) -> Void) { // Do nothing } } class MockService: Service { init() { super.init(apiClient: MockAPIClient()) } }
72. class MockViewModel: ViewModel { init() { super.init(service: MockService()) } override func fetchData() { /* Nothing */ } override func numberOfItems() -> Int { return 5 } } // Test let viewController = ViewController(viewModel: MockViewModel()) assert(viewController.numberOfRows(inSection: 0), 5)
73. Isolation is too expensive in Swift
74. Reflection defeats static typing
75. Other ways to break the dependency graph 1. NSObject 2. Protocols
76. 1. NSObject
77. func dummy<T: AnyObject>(someClass: T.Type) -> T { return unsafeBitCast(NSObject(), someClass) }
78. Problem solved !
79. Poor man's Swift
80. Method cannot be marked @objc because its result type cannot be represented in Objective-C
81. No sum types !
82. Go back to Objective-C
83. NSProxy & NSInvocation
84. 2. Protocols
85. NO
86. This is over-abstraction and the dreaded “design damage” — Uncle Bob
87. Interfaces should be used for: 1. Change tolerance 2. Decouple from volatile dependencies
88. Two types of dependencies: 1. Stable: view model, interactor, service, parsers 2. Volatile: database, network, I/O, navigator
89. Control volatile dependencies Because we want deterministic tests
90. Forget about stable dependencies
91. Collaborators are implementation details
92. Testing collaborators interaction couples you to those details
93. let result = multiple(addFunction: f, number: 7, times: 10) verify(f, with: 7, times: 10)
94. Volatile dependencies: To DI or not to DI
95. ViewController | ViewModel | Service | APIClient
96. ViewController | ViewModel | Service | MockAPIClient
97. let service = Service(apiClient: MockAPIClient()) let viewModel = ViewModel(service: service) let viewController = ViewController(viewModel: viewModel)
98. DI pollutes your code
99. Pros • Inversion of control • Explicit dependencies • Isolation • Loosely coupling • Promote good separation of concerns and SRP • Object creation responsibility
100. Cons • Code coupled to the DI framework you use • Boilerplate infra for injector • Ugly factories and providers all around when going extreme • Touch 10 classes for a tiny naive change • Writing more code to support testing than the actual code you are testing
101. DI legitimize bad architecture — I'm not saying this
102. Is there a better way?
103. Volatile dependencies Environment
104. Environment Stack
105. Arrange Push controlled environment onto the stack
106. Cleanup Pop environment from the stack
107. // Setup Environment.push(apiClient: MockAPIClient()) let viewController = ViewController() // Cleanup Environment.pop()
108. Pointfree
109. var Current = Environment() struct Environment { var apiClient = APIClient() }
110. // Setup Current.apiClient = MockAPIClient() let viewController = ViewController() // Cleanup Current = .init()
111. Ambient context
112. Problems
113. Problems 1. Context available everywhere, for everybody.
114. Problems 1. Context available everywhere, for everybody. 2. You don't know what you class depends upon. What to control? Not explicit.
115. Problems 1. Context available everywhere, for everybody. 2. You don't know what you class depends upon. What to control? Not explicit. 3. Problems might arise if run in parallel
116. Smell
117. Smell Trade-off
118. Coeffects
119. Now it's time for effects...
120. Mocking
121. Mocking Some part of your real code is not being tested
122. We want to test as much real code as possible
123. Mocks returning mocks
124. Coupled to implementation details
125. Tests broken after naive refactors
126. Worse in dynamic languages
127. Is there a better way?
128. Look outside
129. React native
130. view = f(state)
131. Deterministic view renders
133. update : Msg -> Model -> (Model, Cmd Msg)
134. Effects as values
135. enum Effect { case apply(id: Job.Id) } func apply( to job: Job, currentUser: User, ) -> Effect? { guard currentUser.canApply else { return nil } return .apply(id: job.id) }
136. enum Effect { case apply(id: Job.Id) } func apply( to job: Job, api: API, currentUser: User, ) -> Effect? { guard currentUser.canApply else { return nil } return .apply(id: job.id) }
137. assertEqual( apply(to: job, api: api, currentUser: user), Effect.apply(id: 5) )
138. Pure function
139. Pure function Easy testing, type reasoning...
140. class EffectHandler { func handle(effect: Effect) { switch effect { case .apply(let id): Current.apiClient.apply(id) // actual effect } } }
141. Impure part
142. Mocks only test intention
143. Values capture intention better
144. Values as boundaries
145. Functional core
146. Imperative shell
147. Boundaries — Gary Bernhardt
148. Separating logic from effects Affordable integration tests
149. A -> B -> C Cyclomatic complexity = 2
150. Unit tests 2 + 2 + 2 = 6
151. Integration tests 2 * 2 * 2 = 8
152. Integration testing doesn't scale
153. Moving effect decision to pure-land reduces code paths on impure-land
154. Effect handler without logic It just pulls the trigger
155. Logic is tested via unit tests
156. Effects are tested via integration tests
157. Value snapshots
158. APIClient Request<T> is the value func send<T: Decodable>(request: Request<T>) -> Future<T>
160. Navigator Navigation is the value func handle(navigation: Navigation) enum Navigation { case modal(Screen) case push(Screen) } enum Screen { case job(String) case privateInfo var viewController: UIViewController { switch self { case .process(let id): ... case .privateInfo: ... } }
162. struct Environment { var apiClient = APIClient() var navigator = Navigator() }
163. Inspired by Elm
164. Lwift v2
165. protocol State: Equatable { associatedtype Event = NoEvent associatedtype Effect = NoEffect mutating func handle(event: Event) -> Effect? }
166. protocol Effects { associatedtype S: State func handle(effect: S.Effect) -> Future<S.Event, NoError>? }
167. class Store<S: State> { init<E: Effects>(effects: E, initialState: S) where E.S == S { self.effects = .init(effects) _state = initialState } func subscribe(_ block: @escaping (S) -> Void) -> Subscription<S> { ... } func dispatch(event: S.Event) -> Future<S, NoError> { ... } }
168. Show me the code
169. struct JobListViewState { var jobs = LoadingState<[Job], Error>() enum Event { case viewDidLoad case userDidRefresh case jobsDownloaded([Job]) case errorDidArise(Error) case applyToJob(Job) } enum Effect { case downloadJobs case markJobAsApplied(Job.Id) } }
170. mutating func handle(event: Event) -> Effect? { switch event { case .userDidRefresh: guard !jobs.isLoading else { return nil } jobs.toLoading() return .downloadJobs case .jobsDownloaded(let jobs): jobs.toLoaded(with: jobs) return nil case .applyToJob(let job): return .markJobAsApplied(job.id) } }
171. Views can subscribe... subscribe(to: store) subscribe(to: store, keyPath: \.jobs) subscribe(to: store, transform: viewStateFromStoreState) subscribe(to: store, predicate: { $0.jobs.isLoaded })
172. Views can subscribe... subscribe(to: store) subscribe(to: store, keyPath: \.jobs) subscribe(to: store, transform: viewStateFromStoreState) subscribe(to: store, predicate: { $0.jobs.isLoaded }) ...and send events store.dispatch(event: .userDidRefresh)
173. Jobs are downloaded when the view is shown let state = JobListViewState() assertEqual(state.handle(.viewDidLoad), .downloadJobs)
174. Jobs are not downloaded again let state = JobListViewState() state.handle(.viewDidLoad) assertNil(state.handle(.userDidRefresh))
175. State snapshot let state = JobListViewState() state.handle(.viewDidLoad) assertSnapshot(matching: state)
176. class JobListViewEffects { func handle(effect: S.Effect) -> Future<S.Event, NoError>? { switch effect { case .downloadJobs: return Current.apiClient .send(request: DownloadJobsRequest()) .map(S.Event.jobsDownloaded) } } }
177. View snapshot Current .apiClient[NotificationsRequests.DownloadJobsRequest()] = .success(.json("JobList")) assertSnapshot(matching: JobListViewController())
178. Three more things for full happiness
179. 1. Know why it failed easily
180. struct Job { var id: String var name: String var applicants: [User] }
184. Encodable state
185. 2. Fixtures
186. Object mother
187. extension Job { static func mock( id: String = "4-8-15-16-23-42", name: String = "Waiter", applicants: [User] = [User].mock(), ) -> Job { return self.init(id: id, name: name) } } let mockJob = Job.mock(name: "Barista")
188. Boilerplate infra
189. Sourcery
190. Decodable
191. extension Array where Element == Job { static func template(jsonFile: String = "jobs.json") -> [Job] { // Read from file and decode using Decodable } } let mockJob = [Job].template().first!.with(\.name, "Barista")
192. var is fine
193. 3. Your tests must run synchronously
194. Your tests must run synchronously 1. APIClient
195. Your tests must run synchronously 1. APIClient 2. Futures execution context
196. protocol APIClientProtocol { func send<T: Decodable>(request: HTTPRequest) -> Future<T, Error> }
197. protocol APIClientProtocol { func send<T: Decodable>(request: HTTPRequest) -> Future<T, Error> } class APIClientMock: APIClientProtocol { subscript(request: HTTPRequest) -> Response { get { return requestToJSONMap[request.hash]! } set(newValue) { requestToJSONMap[request.hash] = newValue } } }
198. protocol APIClientProtocol { func send<T: Decodable>(request: HTTPRequest) -> Future<T, Error> } class APIClientMock: APIClientProtocol { subscript(request: HTTPRequest) -> Response { get { return requestToJSONMap[request.hash]! } set(newValue) { requestToJSONMap[request.hash] = newValue } } func send<T: Decodable>(request: HTTPRequest) -> Future<T, Error> { switch self[request] { case .success(let json): return Future(value: try! decodeJSON(from: json.fileName) as T) case .failure(let failure): return Future(error: generateError(from: failure)) } } }
199. ImmediateExecutionContext struct Environment { var executionContext: ExecutionContext { get { return DefaultThreadingModel() } set { DefaultThreadingModel = { newValue } } } } extension Environment { static let mock: Environment = { var environment = Environment() environment.executionContext = ImmediateExecutionContext return environment }() }
200. Recipe for happiness
201. Recipe for happiness 1. Stop doing DI for controlling coeffects
202. Recipe for happiness 1. Stop doing DI for controlling coeffects 2. Control effects modelling them as values
203. Recipe for happiness 1. Stop doing DI for controlling coeffects 2. Control effects modelling them as values 3. Separate logic from effects
204. Recipe for happiness 1. Stop doing DI for controlling coeffects 2. Control effects modelling them as values 3. Separate logic from effects 4. Unit tests for logic. Integration tests for the rest
205. Recipe for happiness 1. Stop doing DI for controlling coeffects 2. Control effects modelling them as values 3. Separate logic from effects 4. Unit tests for logic. Integration tests for the rest 5. Leverage state snapshots
206. Recipe for happiness 1. Stop doing DI for controlling coeffects 2. Control effects modelling them as values 3. Separate logic from effects 4. Unit tests for logic. Integration tests for the rest 5. Leverage state snapshots 6. Use jsons to avoid boilerplate fixtures
207. Recipe for happiness 1. Stop doing DI for controlling coeffects 2. Control effects modelling them as values 3. Separate logic from effects 4. Unit tests for logic. Integration tests for the rest 5. Leverage state snapshots 6. Use jsons to avoid boilerplate fixtures 7. Make your tests synchronous
210. Nobody knows how to build software — Alan Cooper
211. Nobody knows how to build software — Alan Cooper Luis Recuenco
212. Gratitude
214. Never stop testing
215. Thanks