Efeitos colaterais em apps iOS: isolando-os e atingindo máxima testabilidade na prática

Código que lida apenas com funções puras e valores imutáveis em vez de objetos complexos pode ser executado com a certeza de que só o que importa são valores de saída em relação a valores de entrada. Este tipo de código oferece máxima testabilidade, mas vem com uma dúvida fundamental: como escrever aplicações reais dessa forma, sem comunicação com a Internet ou sem persistência local?

Nesta palestra vamos conhecer como aplicar conceitos de programação funcional na vida real, isolando completamente o gerenciamento de efeitos colaterais como I/O ou acesso aos sensores do dispositivo e solucionando problemas que existem hoje, deixando a parte impura da aplicação com pouca ou nenhuma lógica.

Transcript

1. Efeitos colaterais em apps iOS Isolando-os e atingindo máxima testabilidade
 na prática
2. final class LoginViewController: UIViewController { private let loginService = Environment.current.loginService // ... override func viewDidLoad() { super.viewDidLoad() loginButton.addTarget(self, action: #selector(performLogin(_:)), for: .touchUpInside ) } @objc private func performLogin(_ sender: UIButton) { let validation = LoginValidation( login: loginTextField.text, password: passwordTextField.text ) switch validation { case let .success(login, password): activityIndicator.startAnimating() loginService.perform(login: login, password: password) { [weak self] result in self?.interpret(result: result) self?.activityIndicator.stopAnimating() } case let .failed(error): interpret(validationError: error) } } }
3. Existem algumas abordagens possíveis para testar o código deste view controller. 
 Dentre elas: 1. Em isolamento 2. De forma integrada
4. Existem algumas abordagens possíveis para testar o código deste view controller. 
 Dentre elas: 1. Em isolamento 2. De forma integrada
5. final class LoginViewController: UIViewController { private let loginService = Environment.current.loginService // ... override func viewDidLoad() { super.viewDidLoad() loginButton.addTarget(self, action: #selector(performLogin(_:)), for: .touchUpInside ) } @objc private func performLogin(_ sender: UIButton) { let validation = LoginValidation( login: loginTextField.text, password: passwordTextField.text ) switch validation { case let .success(login, password): activityIndicator.startAnimating() loginService.perform(login: login, password: password) { [weak self] result in self?.interpret(result: result) self?.activityIndicator.stopAnimating() } case let .failed(error): interpret(validationError: error) } } }
6. struct Environment { private static var stack: [Environment] = [.default] static var current: Environment { return stack.last! } private static var `default`: Environment { return .init(loginService: LoginService()) } static func push(loginService: LoginServiceProtocol) { stack.append(.init(loginService: loginService)) } @discardableResult static func pop() -> Environment? { return stack.popLast() } let loginService: LoginServiceProtocol }
7. final class LoginViewControllerTests: XCTestCase { func testLoginInCaseOfSuccess() { let loginService = StubLoginService(result: .success(/* ... */)) Environment.push(loginService: loginService) let loginViewController = LoginViewController() XCTAssert(loginViewController.view != nil) loginViewController.loginTextField = /* ... */ loginViewController.passwordTextField = /* ... */ loginViewController.loginButton.sendActions(for: .touchUpInside) XCTAssertFalse(loginViewController.activityIndicator.isAnimating) Environment.pop() } }
8. ! Test Driven Design
9. ! TDD de fora para dentro
10. ! Performance dos testes
11. " Necessidade de mocks
12. Existem algumas abordagens possíveis para testar o código deste view controller. 
 Dentre elas: 1. Em isolamento 2. De forma integrada
13. ?
14. TESTES INTEGRADOS
 SÃO UM GOLPE
15. TESTES INTEGRADOS
 SÃO UM GOLPE EXIGEM CUIDADO
16. Caminhos possíveis de execução
17. Tempo de execução da suíte
18. Como testar esse código sem mocks e sem testes de integração?
19. Usando valores nas fronteiras
20. Actions Store Dispatcher Reducers State Views
21. Views Actions Store Dispatcher Reducers State Views Remote APIs Filesystem Analytics Databases Middleware
22. final class LoginViewController: UIViewController { private let loginService = Environment.current.loginService // ... override func viewDidLoad() { super.viewDidLoad() loginButton.addTarget(self, action: #selector(performLogin(_:)), for: .touchUpInside ) } @objc private func performLogin(_ sender: UIButton) { let validation = LoginValidation( login: loginTextField.text, password: passwordTextField.text ) switch validation { case let .success(login, password): activityIndicator.startAnimating() loginService.perform(login: login, password: password) { [weak self] result in self?.interpret(result: result) self?.activityIndicator.stopAnimating() } case let .failed(error): interpret(validationError: error) } } }
23. final class LoginViewController: UIViewController { private let dispatch: (Action) -> Void init (dispatch: @escaping (Action) -> Void) { super.init(nibName: nil, bundle: nil) self.dispatch = dispatch } // ... override func viewDidLoad() { super.viewDidLoad() loginButton.addTarget(self, action: #selector(performLogin(_:)), for: .touchUpInside ) } @objc private func performLogin(_ sender: UIButton) { let validation = LoginValidation( login: loginTextField.text, password: passwordTextField.text ) switch validation { case let .success(login, password): dispatch(LoginAction.perform(login: login, password: password)) case let .failed(error): interpret(validationError: error) } } }
24. func LoginReducer(state: LoginState, action: LoginAction) -> LoginState { var newState = state switch action { case .perform: newState.isPerforming = true case let .success(user): newState.isPerforming = false newState.loggedInUser = user newState.error = nil case let .failure(error): newState.isPerforming = false newState.loggedInUser = nil newState.error = error } return newState }
25. func LoginMiddleware() -> Middleware<LoginState, LoginAction> { return { getState, dispatch in { next in { action in next(action) guard case let LoginAction.perform(login, password) = action else { return } let loginService = Environment.current.loginService loginService.perform(login: login, password: password) { result in switch result { case let .success(user): dispatch(LoginAction.success(user)) case let .failure(error): dispatch(LoginAction.failure(error)) } } }}} }
26. // Um nível acima do LoginViewController private let store: Store<LoginState, LoginAction> private var subscriptionToken: SubscriptionToken? // ... subscriptionToken = store.subscribe { state in loginViewController.render(state: state) } final class LoginViewController: UIViewController { // ... func render(state: LoginState) { if state.isPerforming { activityIndicator.startAnimating() } else { activityIndicator.stopAnimating() } } }
27. Views LoginAction Store Dispatcher LoginReducer LoginState LoginViewController Login API Login
 Middleware
28. Reducers são o core da aplicação em termos de regras de negócio
29. func LoginReducer(state: LoginState, action: LoginAction) -> LoginState { var newState = state switch action { case .perform: newState.isPerforming = true case let .success(user): newState.isPerforming = false newState.loggedInUser = user newState.error = nil case let .failure(error): newState.isPerforming = false newState.loggedInUser = nil newState.error = error } return newState }
30. + Caminhos de execução
 + Decisões
 Completamente isolados
 Puramente funcionais
 
 Cenário ideal para testes unitários
31. Middleware são o shell da aplicação, mas na parte de trás
32. func LoginMiddleware() -> Middleware<LoginState, LoginAction> { return { getState, dispatch in { next in { action in next(action) guard case let LoginAction.perform(login, password) = action else { return } let loginService = Environment.current.loginService loginService.perform(login: login, password: password) { result in switch result { case let .success(user): dispatch(LoginAction.success(user)) case let .failure(error): dispatch(LoginAction.failure(error)) } } }}} }
33. - Caminhos de execução
 - Decisões
 + Dependências
 
 Cenário ideal para testes integrados
34. Views são o shell da aplicação, mas na parte da frente
35. - Caminhos de execução
 - Dependências
 + Decisões
 
 Tornam-se mais simples de testar usando métodos como testes de UI e snapshots
36. - Caminhos de execução
 - Dependências
 + Decisões
 
 Decisões de apresentação podem ser encapsuladas em camadas intermediárias (e. g. view models)
37. Substituir as dependências por valores
38. Testar as interações com valores de entrada
39. Testar a produção de valores de saída
40. Obrigado!
41. Fellipe Caetano
 
 ✉ fellipe.caetano@sympla.com.br
 fellipecaetano_
 fellipecaetano