Escreva testes úteis

#testing

Testes de software são constantemente negligenciados e vítimas da falsa sensação de baixa produtividade quando se dá o primeiro passo nesse mundo.

Muitos projetos com a mentalidade #GoHorse crescem de forma rápida e dinâmica, sem se importar muito com o alicerce e definições. Porém, o galopar desse cavalo imponente e selvagem pode se transformar em um belo de um tropeço, uma queda bem feia e muito esforço desnecessário para recolocá-lo em movimento.

Testes são o equilíbrio entre o código que se escreve para atingir um comportamento esperado pelas pessoas.

Fluxograma de um software

Gosto de pensar que qualquer software é definido pelo fluxograma abaixo.

Perceba que o usuário interage com as regras de negócio através da UI. Essa interação gera uma nova atualização no estado, pois a própria regra tinha esse foco ou a busca por dados teve a culpa nessa atualização. Também é possível ver que indiretamente, o usuário busca, constantemente, por dados em nossas aplicações através de um intermediador.

Para que os testes se comuniquem com esse fluxograma, definem-se alguns pontos.

Testes devem testar comportamentos

O objetivo central de testes de software é garantir a integridade de uma aplicação. Indo um pouco além, testes devem focar em testar comportamento de pessoas.

O comportamento é definido como o conjunto de ação-reação de um sistema dinâmico.

Portanto, as pessoas não estão interessadas em qual padrão de software foi usado no projeto, muito menos a linguagem. Elas querem interagir com a aplicação da forma mais fluida possível.

Todos os testes devem ser uma combinação de ações que simula a interação de uma pessoa e testar a sua percepção às mudanças sempre que necessário.

Testes devem ter foco

Aliado ao conceito de comportamento, os testes precisam de foco.

Não é interessante misturar comportamentos em um mesmo teste, pois em situações onde é necessário dar a manutenção no software, não será fácil mapear qual comportamento está com problema.

Ter foco também ajuda a entender onde começa e termina cada teste. Dessa forma, tem-se uma base de testes mais enxuta, direta ao ponto e de fácil manutenção.

Testes devem ser previsíveis

Previsibilidade em testes significa que independente de quantas vezes serão executados, dado uma mesma entrada, a mesma saída deverá retornada.

Testes previsíveis contribuem para uma boa manutenção de todo o ecossistema, ajuda na leitura e entendimento, além de estabelecer marcos bem definidos.

Testes não devem modificar controles internos, muitos menos manipular estados.

É intuitivo pensar que se deve utilizar mocks para controlar as Regras de Negócio do sistema.

Gosto de pensar que Mocks é uma ferramenta que permite simular retornos específicos de comportamentos reais implementados.

Essa decisão pode ser perigosa, pois é muito fácil chegar em um aglomerado de testes que combinam diversas situações das regras de negócio, mas que no fundo pouco agrega na integridade do software.

Testar todas essas possibilidades tiram as pessoas do ponto central do porque se escreve testes de software e as regras de negócio tomam esse lugar. Com essa pequena mudança, os comportamentos estão limitados, agora, àquilo que se escreveu, não mais ao que as pessoas conseguem fazer.

Portanto, as regras de negócio devem sempre apoiar as decisões das pessoas durante uma interação e o foco é, justamente, em testar essas decisões.

Testes só devem manipular aquilo que é retornado para a camada de negócio

Quando é necessário buscar por dados (APIs, Banco de Dados, Cache, etc), sabe-se que as regras de negócio reagem de forma diferente dependendo de como essa informação é retornada.

Essas reações produzem atualizações de estados e que são apresentados na UI.

Já foi dito que as pessoas interagem com os dados por meio das regras de negócio. Essa interação pode ser bem sucedida ou não. Além disso, a regra de negócio tem o dever de alterar a UI para um estado de espera até que se termine a busca por esses dados.

Para que os testes sejam sempre previsíveis é preciso utilizar dos mocks para controlar os possíveis retornos (sucesso ou falha) dos agentes. Dessa forma, é possível testar todas as percepções das pessoas enquanto estão esperando pelos dados, quando são bem sucedidas e podem continuar ou quando ocorre uma falha do sistema.

Novamente, os testes se limitam àquilo que as pessoas conseguem fazer.

Testes não são fáceis de construir

Por fim, gostaria de ressaltar que construir bons testes é tão difícil quanto construir software. É preciso determinação e bastante conhecimento para evitar duplicação de código e facilitar a sua manutenção, que é constante.

É preciso ter responsabilidade ao construir testes, pois são mais linhas de código que requer atenção e que vão agregar em todo o sistema construído.

Conclusão

Encerro essa discussão sobre como escrever bons testes de software e que sejam úteis para o seu negócio. Precisamos ser mais pragmáticos e sempre escrever software com o propósito de atender as pessoas.

Adoraria escutar a opinião de vocês! Fiquem à vontade para estender esse assunto nos comentários.

Um abraço e até a próxima :)