Efeitos colaterais em apps iOS

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. Injeção de dependências?
7. 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 }
8. 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() } }
9. ! Test Driven Design
10. ! TDD de fora para dentro
11. ! Performance dos testes
12. " Necessidade de mocks
13. Existem algumas abordagens possíveis para testar o código deste view controller. 
 Dentre elas: 1. Em isolamento 2. De forma integrada
14. ?
15. TESTES INTEGRADOS
 SÃO UM GOLPE
16. Caminhos possíveis de execução
17. Tempo de execução da suíte
18. TESTES INTEGRADOS
 SÃO UM GOLPE EXIGEM CUIDADO
19. Como minimizar os testes de integração sem abrir mão de testar as integrações?
20. Usando valores nas fronteiras
21. Actions Store Dispatcher Reducers State Views
22. Views Actions Store Dispatcher Reducers State Views Remote APIs Filesystem Analytics Databases Middleware
23. 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) } } }
24. 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) } } }
25. 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 }
26. 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)) } } }}} }
27. // 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() } } }
28. Views LoginAction Store Dispatcher LoginReducer LoginState LoginViewController Login API Login
 Middleware
29. Reducers são o núcleo da aplicação em termos de regras de negócio
30. 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 }
31. + Caminhos de execução
 + Decisões
 Completamente isolados
 Puramente funcionais
 
 Cenário ideal para testes unitários
32. Middleware são a casca de trás da aplicação
33. 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)) } } }}} }
34. - Caminhos de execução
 - Decisões
 + Dependências
 
 Cenário ideal para testes integrados
35. Views são a casca da frente da aplicação
36. - Caminhos de execução
 - Dependências
 + Decisões
 
 Tornam-se mais simples de testar usando métodos como testes de UI e snapshots
37. - Caminhos de execução
 - Dependências
 + Decisões
 
 Decisões de apresentação podem ser encapsuladas em camadas intermediárias (e. g. view models)
38. Substituir as dependências por valores
39. Testar as interações com valores de entrada
40. Testar a produção de valores de saída
41. Perguntas?
42. Fellipe Caetano
 
 Especialista em desenvolvimento iOS com 7+ de experiência implementando aplicações de nível enterprise para diversos segmentos.
 
 Atua como líder técnico de desenvolvimento iOS na Sympla. fellipe.caetano@sympla.com.br fellipecaetano fellipecaetano_
43. Obrigado!