Swift - TDD, Clean Architecture, Design Patterns, SOLID, MVP

Nessa aula irei mostrar como fazer para integrar nossos casos de uso com um Client HTTP, sem acoplar os UseCases com nenhum framework. Iremos fazer um teste para garantir que o HttpClient vai ser chamado com a URL correta.

Nessa aula irei mostrar como fazer para garantir que o HttpClient irá receber os dados corretos para utilizar no body da requisição. Irei também mostrar como fazer para refatorar o código para manter sempre limpos os códigos dos testes e de produção.

Nessa aula irei mostrar como testamos métodos assíncronos. Iremos testar o callback do AddAccount UseCase baseado no callback do HttpClient.

Nessa aula irei testar os casos onde recebemos dados do HttpClient, mas devemos testar se eles são válidos ou não. Além disso irei mostrar uma maneira muito boa de refatorar os testes.

Nessa aula irei mostrar como fazer testes para garantir que nossos componentes não tenham memory leaks.

Nessa aula irei mostrar como fazer para testar o Alamofire (ou qualquer outra biblioteca que faz Request) sem precisar mockar a biblioteca em questão. Existe uma classe (URLProtocol) no Swift que permite que a utilizemos para interceptar os requests e com isso podemos fazer testes unitários sem fazer requisições reais.

Nessa aula vou mostrar como faremos para testar os dados recebidos no body do request. Além disso vou fazer alguns refactors importantes.

Nessa aula irei testar os possíveis casos de retorno de um request. Um request válido deve retornar um erro ou dados e uma resposta HTTP (com um status code). Porém nada impede que um request retorne combinações inválidas, por exemplo um erro e dados numa mesma resposta. Ao invés de confiar que o Alamofire nunca vai falhar, podemos criar alguns testes adicionais para esses casos inválidos e, com isso, garantir que nosso app estará coberto por esses casos inesperados.

Nessa aula irei mover os componentes de Infra para seus arquivos, habilitar testes em ordem randômica e usar o recurso de Thread Sanitiser para garantir que nossos testes não falhem caso executados em ordem aleatória ou que não tenham problemas de Data Racing. Além disso irei criar um Schema de CI para rodar todos os testes e gerar cobertura de testes de nossos arquivos. Até o momento estamos com 100% de cobertura.

Nessa aula irei fazer um teste de integração do nosso UseCase AddAccount com uma API externa para garantir que nossas camadas estão funcionando corretamente quando utilizadas em conjunto.

Essa API foi construída por mim em outro curso aqui disponível na Udemy, também utilizando TDD e Clean Architecture e foi publicada no Heroku. Vocês podem utilizá-la para fazer testes.

Segue o link da API:

https://clean-node-api.herokuapp.com/api/signup

Caso tenham interesse no meu curso de Node:

https://www.udemy.com/course/tdd-com-mango/?referralCode=B53CE5CA2B9AFA5A6FA1

Nessa aula irei explicar como funciona o MVP (Model-View-Presenter) e como utilizaremos ele em nosso projeto. Vou iniciar validando os dados do formulário de criação de conta.

Nessa aula irei finalizar todas as validações necessárias para o Presenter. Irei mostrar como desacoplar a validação de email do presenter, criando um protocolo genérico que será implementado por algum Adapter para podermos reutilizar esse componente em qualquer lugar que precise validar email.

Nessa aula irei mostrar uma forma diferente de utilizar o makeSut para evitar de retornar muitas classes numa tupla. Além disso iremos refatorar nosso código para ficar mais legível os testes.

Nessa aula irei tratar o retorno de erro do AddAccount. Nesse caso iremos mostrar uma mensagem de erro utilizando o protocolo AlertView. Como o AlertView é chamado dentro do AddAccount callback, iremos modificar o código de testes e utilizar o design pattern observer, mais uma vez, para garantir que o Assert irá ser executado, já que ele irá ocorrer de forma assíncrona. Além disso iremos criar um protocolo de LoadingView para dizer para a View que estiver utilizando o Presenter para mostrar um loading na tela antes de executar o AddAccount.

Nessa aula irei testar o caso de sucesso do AddAccount. Além disso irei criar um teste para garantir que iremos esconder o loading no fim do completion. Pra finalizar irei fazer um refactor no Presentation Layer criando helpers e movendo arquivos para pastas para organizar melhor o projeto.

Nessa aula irei iniciar a criação do SignUpViewController. Irei criar essa classe como um componente para poder ser criado com todas suas dependências na camada Main (onde fazemos a composição dos objetos). Pela primeira vez iremos precisar criar um target que precisa do iOS. Com isso mostrarei que iremos precisar dar acesso ao iOS pros demais targets, pro build funcionar corretamente.

Nessa aula irei mostrar como garantir com testes que nosso ViewController esteja implementando os protocolos necessários. Além disso irei criar testes para garantir que ao clicar no botão salvar o método signUp será chamado com os valores corretos.

Nessa aula irei criar um layout mais elegante para a tela de SignUp e fazer alguns refactors.

Nessa aula irei criar alguns helpers para ajudar a reduzir código e simplificar algumas operações que são executas com uma certa frequência.

Nessa aula irei criar o EmailValidatorAdapter. É um componente que vai centralizar a lógica de validar email. Ele utiliza o design pattern Adapter que serve para adaptar duas interfaces diferentes e fazer elas se comunicarem de forma correta.

Nessa aula irei fazer a composição do SignUpViewController com todas as suas dependências e mostrar pela primeira vez o nosso app no simulador. Conseguimos criar todos os componentes sem abrir sequer uma vez o simulador. Esse é o poder do TDD.

Nessa aula irei refatorar o Factory do SignUp para deixar ele mais flexível. Vou separar a parte da regra de negócios em outro Factory e a parte de UI vou transformar em Composer (que é um sinônimo de Factory) pra dar mais semântica ao que quero atingir. Vou também demonstrar com um teste que temos um Memory Leak entre o Controller e o Presenter e vou utilizar o design pattern Proxy pra resolver esse problema.

Nessa aula irei mostrar uma forma bem elegante de trabalhar com variáveis de ambiente dentro do Swift.

Nessa aula irei mostrar como fazer tratamento de Threading (requests feitos em background devem ser completados na main thread) utilizando o design pattern Decorator.

Nessa aula irei iniciar a migração da validação dos dados feitos dentro do Presenter para a camada Validation. Vamos utilizar o design pattern Composite para fazer isso de uma forma que possamos, sempre que preciso, alterar a validação, sem precisar alterar nossos componentes o que é um dos princípios do SOLID, o Open Closed Principle.

Nessa aula irei criar 2 validadores: o RequiredFieldValidator e o CompareFieldsValidator. A grande vantagem de criar esses componentes isolados em uma outra camada e utilizar o Composite na hora de compor a classe é que não precisamos duplicar os testes unitários da validação desses campos em cada Presenter nosso. Além disso iremos reaproveitar toda a lógica de validação de um lugar apenas. Se encontramos algum problema basta corrigir em um lugar.

Nessa aula irei criar os 2 últimos validators que faltaram: O EmailValidation e o ValidationComposite.

Nessa aula irei finalizar a migração do Validation. Irei fazer a nova composição do SignUp usando o Composite e injetando nele os Validators que o SignUp precisa. Irei criar testes para garantir que o SignUp tenha todos os validadores que precisa. Para finalizar irei mostrar o Git Rebase para juntar os commits parciais que fiz nas últimas aulas.

Fizemos uma mudança na API e o caso de uso do AddAccount agora retorna um accessToken ao invés da conta toda do usuário.

Vamos adaptar nosso projeto também.

Nessa aula irei finalizar o refactor por causa da mudança na API. Vou alterar o teste de integração para apontar para a nova API, adicionar novos testes e refatorar algumas coisas no projeto para melhorar a legibilidade do código

Nessa aula irei criar a nova interface do projeto e criar alguns componentes reaproveitáveis

Nessa aula irei criar a implementação do caso de uso Authentication usando API. Vamos reaproveitar a base de testes do RemoteAddAccount para o RemoteAuthentication mais rápido dessa vez, mas sempre fazendo teste a teste.

Nessa aula irei iniciar os testes e criação do LoginPresenter. Vou integrar com o Authentication UseCase e com o Validation.

Nessa aula irei finalizar os testes e desenvolvimento do LoginPresenter

Nessa aula irei criar a intrface e o Controller do Login com seus testes

Nessa aula irei criar os Factories para o Login e fazer os testes necessários

Nessa aula irei criar a primeira tela do App, onde o usuário irá decidir se vai fazer cadastro ou login.

Nessa aula mostrarei como fazer a navegação entre componentes de forma desacoplada e com testes.

Nessa aula irei fazer um refactor nos factories para deixar a composição mais limpa

Nessa aula irei simplificar a criação dos Validations com o Design Pattern Builder.