Escreva testes teis

Testes de software so constantemente negligenciados e vtimas da falsa sensao de baixa produtividade quando se d o primeiro passo nesse mundo.

Muitos projetos com a mentalidade #GoHorse crescem de forma rpida e dinmica, sem se importar muito com o alicerce e definies. Porm, o galopar desse cavalo imponente e selvagem pode se transformar em um belo de um tropeo, uma queda bem feia e muito esforo desnecessrio para recoloc-lo em movimento.

Testes so o equilbrio entre o cdigo 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 usurio interage com as regras de negcio atravs da UI. Essa interao gera uma nova atualizao no estado, pois a prpria regra tinha esse foco ou a busca por dados teve a culpa nessa atualizao. Tambm possvel ver que indiretamente, o usurio busca, constantemente, por dados em nossas aplicaes atravs 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 aplicao. Indo um pouco alm, testes devem focar em testar comportamento de pessoas.

O comportamento definido como o conjunto de ao-reao de um sistema dinmico.

Portanto, as pessoas no esto interessadas em qual padro de software foi usado no projeto, muito menos a linguagem. Elas querem interagir com a aplicao da forma mais fluida possvel.

Todos os testes devem ser uma combinao de aes que simula a interao de uma pessoa e testar a sua percepo s mudanas sempre que necessrio.

Testes devem ter foco

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

No interessante misturar comportamentos em um mesmo teste, pois em situaes onde necessrio dar a manuteno no software, no ser fcil mapear qual comportamento est com problema.

Ter foco tambm ajuda a entender onde comea e termina cada teste. Dessa forma, tem-se uma base de testes mais enxuta, direta ao ponto e de fcil manuteno.

Testes devem ser previsveis

Previsibilidade em testes significa que independente de quantas vezes sero executados, dado uma mesma entrada, a mesma sada dever retornada.

Testes previsveis contribuem para uma boa manuteno de todo o ecossistema, ajuda na leitura e entendimento, alm de estabelecer marcos bem definidos.

Testes no devem modificar controles internos, muitos menos manipular estados.

intuitivo pensar que se deve utilizar mocks para controlar as Regras de Negcio do sistema.

Gosto de pensar que Mocks uma ferramenta que permite simular retornos especficos de comportamentos reais implementados.

Essa deciso pode ser perigosa, pois muito fcil chegar em um aglomerado de testes que combinam diversas situaes das regras de negcio, 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 negcio tomam esse lugar. Com essa pequena mudana, os comportamentos esto limitados, agora, quilo que se escreveu, no mais ao que as pessoas conseguem fazer.

Portanto, as regras de negcio devem sempre apoiar as decises das pessoas durante uma interao e o foco , justamente, em testar essas decises.

Testes s devem manipular aquilo que retornado para a camada de negcio

Quando necessrio buscar por dados (APIs, Banco de Dados, Cache, etc), sabe-se que as regras de negcio reagem de forma diferente dependendo de como essa informao retornada.

Essas reaes produzem atualizaes de estados e que so apresentados na UI.

J foi dito que as pessoas interagem com os dados por meio das regras de negcio. Essa interao pode ser bem sucedida ou no. Alm disso, a regra de negcio 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 previsveis preciso utilizar dos mocks para controlar os possveis retornos (sucesso ou falha) dos agentes. Dessa forma, possvel testar todas as percepes das pessoas enquanto esto esperando pelos dados, quando so bem sucedidas e podem continuar ou quando ocorre uma falha do sistema.

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

Testes no so fceis de construir

Por fim, gostaria de ressaltar que construir bons testes to difcil quanto construir software. preciso determinao e bastante conhecimento para evitar duplicao de cdigo e facilitar a sua manuteno, que constante.

preciso ter responsabilidade ao construir testes, pois so mais linhas de cdigo que requer ateno e que vo agregar em todo o sistema construdo.

Concluso

Encerro essa discusso sobre como escrever bons testes de software e que sejam teis para o seu negcio. Precisamos ser mais pragmticos e sempre escrever software com o propsito de atender as pessoas.

Adoraria escutar a opinio de vocs! Fiquem vontade para estender esse assunto nos comentrios.

Um abrao e at a prxima :)