O que são testes automatizados na programação?

Essa dúvida era recorrente enquanto estava estudando programação sozinho, em diversos vídeos e artigos, todos falavam da sua importância, e de como evita a introdução de novos bugs e do quanto pode salvar sua sexta feira a noite.

Porém eu tinha dúvida do que exatamente era isso, achava poucos artigos partindo do zero, e tinha bastante dificuldade de como dar o primeiro passo. Como escrever o primeiro teste? Como executar? Quais são as diferentes formas de testar sua aplicação? O porquê dos Designs Patterns serem importantes?

Eu só fui solucionando essas respostas com o tempo e a partir de hoje começarei escrevendo uma série de artigos sobre tudo o que aprendi sobre os testes.

Iniciando na parte mais fundamental.

O que é?

Testes são apenas uma forma de você garantir que uma funcionalidade esteja sendo corretamente executada. Meio confuso? Pois bem, vamos a um exemplo.

Eu tenho uma lista com todos os pokemons e quando eu clico, abre um dialog com suas características detalhadas.

Atualmente o código funciona perfeitamente, mas pode ser que futuramente algum outro desenvolvedor faça alguma alteração no código que pare de abrir o modal, e agora? Se ele esquecer de testar manualmente essa funcionalidade, os usuários terão uma péssima experiência. Para isso, eu posso escrever um teste que sempre que ao enviar o código para produção ele é executado e garanta que essa funcionalidade esteja perfeitamente funcionando.

teste para verificar se o dialog é aberto

No próximo artigo explico melhor o que cada comando faz, mas inicialmente basta saber que eu simulo um click na div do pokemon e depois verifico se o o método de abrir o dialog foi chamado, com os devidos argumentos. Caso o teste não passa serei notificado.

Depois dessa introdução vou citar os principais motivos de SEMPRE criar testes enquanto está desenvolvendo suas aplicações.

• Economiza tempo e dinheiro: o pior cenário na sua equipe de programação é ficar resolvendo bugs, pois é tempo que poderia ser aproveitado enquanto agrega mais funcionalidades ao seu negócio, ao invés de ficar refazendo o trabalho. Ao fazer testes, não significa que sua aplicação esteja isenta de bugs, mas a maioria deles serão evitados e você terá um trabalho mais fácil para mapear da onde aquele bug pode ter sigo ocasionado, baseado nos seus próprios testes.
• Facilita leitura e manutenção: os testes eles formalizam todos os requerimentos do seu software, ou seja, apenas lendo o teste, vc sabe o que cada função deve fazer, sem precisar adivinhar qual é a regra de negócio em cada parte da aplicação.
• Novas funcionalidades sem medo de quebrar o que já existe: Conforme sua aplicação cresce, fica difícil verificar os impactos de uma mudança em cada segmento da aplicação, dessa forma os testes são uma forma de garantir o funcionamento da aplicação, independente das alterações feitas, de forma a não destruir o que já foi feito.

Se os testes possuem todos esses benefícios, por que algumas empresas não utilizam ?

O principal empecilho que vejo algumas empresas, principalmente em startups, é não criar testes até possuir um MVP (Mínimo Produto Viável) e depois que conseguir dinheiro de investimento, aumentar a quantidade de programadores, e consequentemente, melhorar o software. Isso ocorre, porque inicialmente é uma corrida contra o tempo para entregar um produto viável e a ideia ser validada.

Contudo, é uma decisão de negócio, que varia em cada caso, mas se você optar por não escrever testes por atrasar o desenvolvimento de novas funcionalidades, o código terá muito mais bugs, será mais difícil de realizar manutenção e é muito provável que terá que refatorar uma grande parte, resultando no dobro de trabalho. Um termo comumente usado é você está criando um débito técnico.

Qual a quantidade de testes que minha aplicação deve ter?

Já foi explicado que não ter testes, ou uma baixa quantidade, é prejudicial ao negócio, porém ter muitos testes também pode consumir grande parte do tempo de desenvolvimento, sem acrescentar muitas vantagens ao produto.

Nesse sentido, é melhor identificar quais são as funcionalidades chaves da sua aplicação, como login, busca e feed. Testá-las ao máximo, pois qualquer bug pode ser facilmente percebido pelo usuário final, ao contrário de algumas configurações de perfil, que o usuário nem fica sabendo da sua existência, não há necessidade de testar ao máximo, dependendo do tempo do projeto.

Cobertura de testes na aplicação

Outro fator que auxilia ter um parâmetro da quantidade de testes na sua aplicação é a cobertura de testes, é uma medida calculada baseada na quantidade de linhas do código no qual os testes são executadas em razão do total de linhas.

A primeira ideia que temos é que se tivermos 100% de testes, logo toda aplicação está testada e não vamos ter nenhum bug. O que não é o caso, pois dependendo da qualidade dos testes, ainda podemos ter bugs, além de demandar uma alta quantidade de tempo de desenvolvimento.

Então qual é a quantidade certa de testes? Ainda é um assunto bastante discutido e depende de vários fatores, mas de regra geral, é adotado um valor entre 60% a 80% de cobertura de testes na aplicação, dessa forma você garante todos os benefícios, sem demandar muito tempo desenvolvendo.

Os diferentes tipos de testes

Existem três tipos de testes que podemos escrever.

• Testes Unitários
• Testes de Integração
• Testes End to End (e2e)

Testes Unitários

São testes de mais baixo nível, responsável por testar sua lógica de negócio, geralmente são os mais difíceis de serem escritos se sua arquitetura da aplicação não for bem projetada, pois o código precisa ter um baixo nível de acoplamento entre suas classes.

A ideia inicial é testar cada classe separadamente da outra, sem depender das suas dependências, em caso de classes que precisam de dependência, nós implementamos uma classe fake (Mock) para que seja possível analisar seu funcionamento de modo independente. Além disso, é o tipo de teste que é executado mais rápido.

Testes de Integração

Em alguns casos fica muito difícil isolar uma classe completamente, nesse caso algumas dependências não são "mockadas" (criada uma implementação falsa). Ou seja, nesse tipo de teste você testa um grupo de classes que possuem uma correlação e a sua integração.

Um exemplo é quando se trata de algum banco de dados local, as vezes é melhor não mockar, para facilitar a criação dos testes e verificar se os itens foram criados corretamente.

Porém, como é um teste que não é isolado, fica um pouco difícil em caso do teste falhar, o que exatamente ocasionou esse problema, principalmente em comparação com o teste unitário.

Testes End to End (e2e)

São os testes de alto nível, no qual é simulado um usuário real, e verificamos se o funcionamento de código sem o conhecimento da implementação. Nesse tipo de teste, não são usados mocks, a aplicação é testada toda de uma vez só, dessa forma, quando um teste falha, não temos uma ideia clara do que aconteceu.

Além disso, são os testes que demoram mais tempo para se executar, porque é necessário ter toda a aplicação executando.

Pirâmide de Testes

Logo após a descrição de cada teste, fica claro que é necessário ter uma alta quantidade de testes unitários, pois são os testes que executam mais rápido, são altamente específicos e testam sua lógica de negócio de modo independente, ou seja, em caso de erro, fica fácil identificar o problema e corrigir.

Consequentemente, temos o teste de integração, que possui um nível de acoplamento maior, contudo ainda de forma que seja fácil de identificar o problema e com uma velocidade de execução similar ao teste unitário.

Por fim, o teste e2e é bom para fazer testes de interface e algumas funcionalidades que possuem um impacto em diferentes lugares no software, pois ele engloba o código como um todo, mas é um teste lento.

Logo, no desenvolvimento de software temos o conceito da pirâmide de testes, no qual a base são justamente os testes unitários, seguido por teste de integração e no topo da pirâmide, em menor quantidade, temos os testes e2e.

Obrigado

Este é o fim desse primeiro artigo dessa série de testes, o próximo irá conter exemplos e tutoriais de como criar testes unitários no Angular. E vou explicar mais alguns termos que não ficaram claros como mocks e a real diferença entre cada tipo de teste.