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

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) } } }

Existem algumas abordagens possíveis para testar o código deste view controller. 
 Dentre elas: 1. Em isolamento 2. De forma integrada

Existem algumas abordagens possíveis para testar o código deste view controller. 
 Dentre elas: 1. Em isolamento 2. De forma integrada

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) } } }

Injeção de dependências?

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 }

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() } }

! Test Driven Design

! TDD de fora para dentro

! Performance dos testes

" Necessidade de mocks

Existem algumas abordagens possíveis para testar o código deste view controller. 
 Dentre elas: 1. Em isolamento 2. De forma integrada

?

TESTES INTEGRADOS
 SÃO UM GOLPE

Caminhos possíveis de execução

Tempo de execução da suíte

TESTES INTEGRADOS
 SÃO UM GOLPE EXIGEM CUIDADO

Como minimizar os testes de integração sem abrir mão de testar as integrações?

Usando valores nas fronteiras

Actions Store Dispatcher Reducers State Views

Views Actions Store Dispatcher Reducers State Views Remote APIs Filesystem Analytics Databases Middleware

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) } } }

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) } } }

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 }

func LoginMiddleware() -> Middleware { 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)) } } }}} }

// Um nível acima do LoginViewController private let store: Store 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() } } }

Views LoginAction Store Dispatcher LoginReducer LoginState LoginViewController Login API Login
 Middleware

Reducers são o núcleo da aplicação em termos de regras de negócio

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 }

+ Caminhos de execução
 + Decisões
 Completamente isolados
 Puramente funcionais
 
 Cenário ideal para testes unitários

Middleware são a casca de trás da aplicação

func LoginMiddleware() -> Middleware { 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)) } } }}} }

- Caminhos de execução
 - Decisões
 + Dependências
 
 Cenário ideal para testes integrados

Views são a casca da frente da aplicação

- Caminhos de execução
 - Dependências
 + Decisões
 
 Tornam-se mais simples de testar usando métodos como testes de UI e snapshots

- Caminhos de execução
 - Dependências
 + Decisões
 
 Decisões de apresentação podem ser encapsuladas em camadas intermediárias (e. g. view models)

Substituir as dependências por valores

Testar as interações com valores de entrada

Testar a produção de valores de saída

Perguntas?

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. [email protected] fellipecaetano fellipecaetano_

Obrigado!