Concrete Logo
Hamburger button

Como testar um projeto no View Code com 100% de cobertura

  • Blog
  • 6 de Março de 2017
Share

*Este post foi originalmente publicado (em inglês) no Cocoa Academy. Clique aqui para ver.

Adotar View Code no seu projeto é algo que realmente pode ajudar a torná-lo mais modular. Há algumas semanas, eu escrevi um post aqui no Blog mostrando como migrar um app da Marvel construído com storyboard + xibs para view code. Lá, eu descrevi todos os benefícios de fazermos essa troca, e um deles está relacionado aos testes. O View Code é mais fácil de testar, e portanto sua suíte de testes tende a crescer conforme você adota esse estilo. Hoje vou mostrar como tenho escrito os testes e alguns refactorings que eu fiz durante o projeto. Você pode ver o repositório com os testes aqui.

*O projeto que vou usar nesse post é da Marvel, que eu criei enquanto escrevia uma série de posts. Se você ainda não viu, pode ver aqui.

Por que é mais fácil testar?

Antes de tudo, o View Code permite que você controle o processo de inicialização do seu código. Isso pode não parecer grande coisa, mas confie em mim, é. Agora você pode escrever um inicializador customizado que funciona com tipos fornecidos, o que gera uma série de benefícios:

– Você pode usar uma setter injection dentro do seu ambiente de testes e, por exemplo, fornecer uma implementação (mock) falsa ao invés da verdadeira. Isso ajudará a rodar seus testes isolados, vou falar mais sobre isso adiante;
– Você pode remover Optionals e definir variáveis como constants usando let, já que agora você tem controle sobre o processo do init;
– É mais correto semanticamente, pois vamos dizer que você está criando um view controller de personagem. Você pode tornar obrigatório que alguém forneça um personagem durante o processo init da view controller, o que faz total sentido.

Depois de todo o refactoring e de escrever os testes, eu comecei a tentar melhorar a cobertura do código para chegar a 100%.

lioy1

Cobertura de código não é algo que deveria ser perseguida para buscar um número específico por si só. Ao invés disso, deveria ser usada como um mapa, um guideline que mostrasse dicas de pontos nos quais seu projeto pode melhorar. De certa forma, o real valor da cobertura de código é responder a pergunta: “o que eu vou testar agora?”. Da mesma forma, seus testes deveriam ser usados para refatorar seu código e torná-lo melhor. E melhor significa:

– Mais modular;
– Mais reusável;
– Bem encapsulado;
– Com um propósito claro e simples;
– Mais fácil de evoluir;
– Mais fácil de manter.

Os testes podem ajudar a tornar seu código melhor porque eles fazem você enxergar da mesma perspectiva que alguém que esteja chamando (consumindo) o código. Se você está fazendo um monte de coisas por baixo dos panos é difícil de testar, por isso o refactoring é preciso.

Com ou sem view code

Agora vamos comparar os testes feitos na primeira versão do projeto com storyboard + xibs e, nesta versão, com View Code. Com isso, poderemos ver os benefícios e diferenças entre as duas abordagens.

Teste de CharacterViewController com Storyboard

Teste de CharacterViewController com View Code

Você pode ver que agora, com o View Code, podemos nos livrar de muito do código (boilerplate) usado antes  para a carregar a view controller. Antes, nós não controlávamos o processo de inicialização, e aí tínhamos que recorrer ao storyboard, repetindo a mesma receita. Não mais!

A segunda versão não precisa testar o caso de o character não ser fornecido pela view controller, porque agora ele é um argumento do processo de init, o que significa que se alguém quer a CharacterViewController eles vão precisar fornecer o personagem para o init.

Teste de CharactersViewController

Agora que nós controlamos o init de nossas view controllers, nós podemos fornecer nosso APIManager como um parâmetro para ela, o que abre uma porta para fazermos um setter injection ao mesmo tempo que migramos a variável da APIManager na controller para uma constante usando let, o que faz sentido e torna o código mais seguro. Na versão anterior, sem View Code, a gente tinha que manter como var para fazer a injection, uma vez que não tínhamos controle sobre a inicialização.

Sem View Code

Com View Code

Controlar o processo de inicialização é muito importante, porque te dá muito mais controle sobre todo o seu código! Você pode ver a melhoria no teste da nossa CharactersViewController usando o código:

CharacterTableCell spec

O teste de characterTableCell também foi bem melhorado. Sem o View Code, nós tínhamos que recuperar a célula de novo usando o método cellForRow do datasource, o que significa que nós tínhamos que repetir a mesma receita de carregar uma view controller do Storyboard. Não mais! Agora a gente só precisa iniciar o cell e testar o que quiser.

Componentes, componentes e mais componentes

Uma das coisas mais legais de adotar View Code é que seu código é dividido entre muitos componentes com um propósito único e claro, além dos mesmos serem na sua maioria autocontidos. Isso torna o teste muito mais fácil e remove um monte de mocking e dependências da equação.

Abaixo você pode ver o CharactersCollectionSpec, um teste de um componente autocontido que pode ser plugado em qualquer view controller para oferecer uma coleção de characters. O teste é direto. Na versão anterior (sem View Code) era bem mais difícil testar essa parte do sistema, porque muita coisa estava dentro da view controller. Agora é muito mais específico e claro.

Para onde ir agora?

**Não vou cobrir todos os diferentes casos, acho que você já entendeu a ideia, certo? Com isso, eu recomendo que você clone o projeto para brincar com ele.

Eu realmente acho que o View Code pode melhorar muitas áreas do seu projeto, os testes são só uma delas. Embora seja mais fácil testar um projeto com View Code, isso não significa que seja o único caminho. A versão antiga do projeto da Marvel, construída com Storyboard + Xibs, teve 96% de cobertura de código. Se você quiser saber mais, veja esse post sobre o assunto. A principal diferença é que os testes e o código ficam melhores e mais simples com View Code. Então, tente no seu próximo projeto! Você não vai se arrepender.

Se você tiver algo a comentar ou alguma dúvida, aproveite os campos abaixo. Até a próxima!

É desenvolvedor iOS e quer trabalhar em um time ágil e multidisciplinar? Clique aqui.