Muitos de nós no começo de carreira se preocupam em aprender a como fazer tudo, e essa preocupação é muito justa porque sempre que queremos uma oportunidade recebemos uma lista de coisas que devemos saber fazer. Uma das ideias que aprendi das obras do Robert Cecil Martin, também conhecido como "Uncle Bob", é que quase tão importante quanto saber como se fazer algo é como não fazer.
Por isso aqui me proponho a passar algumas das ideias do que não deve ser feito junto a fundamentação.
2 Passos pra trás
À medida que o software é desenvolvido, ele é testado para garantir que tudo funcione corretamente e identificar bugs, vulnerabilidades ou outros problemas. O teste pode ser feito manualmente (e geralmente é), mas o teste manual é repetitivo e demorado. Assim, os desenvolvedores recorrem aos testes de automação.
O teste de automação é prático e econômico. Como o nome sugere, envolve a automação do processo de teste e o gerenciamento e aplicação de dados e resultados de teste para melhorar o software.
fonte: https://www.atlassian.com/continuous-delivery/software-testing/automated-testing
Para tornar o questionamento mais simples, é importante entender os fundamentos principais para se querer testes automatizados. Para essa discussão focarei em:
- garantia de corretude do código
- reduzir perda de tempo fazendo testes
E não é difícil ver porque essa metodologia ganhou tamanha popularidade da última década, é muito fácil ver que funciona.
Uma verdade é triste e inacreditável pra muita gente, os seus testes podem estar te atrapalhando.
Os testes automatizados podem atrapalhar?
Pelos mesmos motivos que escrever um algoritmo em C não significa que ele será rápido. Não é garantido que o uso dos testes automatizados fará o time ser mais rápido e que nossos testes só passarão quando nosso produto estiver perfeito.
Assim como escrever código performático em C é difícil, escrever bons testes não é tarefa simples. Mas o que poderia acontecer de ruim? E eu te conto alguns exemplos:
- Suite de testes que não testa os casos importantes não traz as garantias que deveria se esperar desses testes, preste atenção para os testes para bater percentual de cobertura. Ex: Uma suite de testes funcionais para um função que somente verifica a soma de 0 e 0 não garante a corretude lógica da função.
- Diversidade de testes já! Suite de testes sem os tipo de teste necessários não da visiblidade sobre os aspectos do produto que são relevantes. Ex: Uma das coisas que se espera de um projeto com um percentual alto de linhas cobertas por testes automatizados é que ele possa ser refatorado. Todavia, se um projeto que tenha fortes requisitos de performance e nenhum teste para isso perdemos essa confiança.
- Testes que não testam nada é um poluente grande de PRs e bases de código inocentes. Do que serve testes unitários para funções rasas que só existem para manter a arquitetura no lugar? Pra mim parece até que a pessoa não confia nela ou nas ferramentas que usa.
- Eu não leio arquivo de teste com mais de mil linhas, até palhaçada tem limites. A Suíte de testes longa grita problemas. As chances da revisão do código seja bem feita são reduzidas, ajustes na suíte de testes para acomodar os novos requisitos fica propensa a falhas. Se já é difícil termos paciência para fazer uma revisão de qualidade em um arquivo de 1000 linhas, é praticamente impossível em uma suíte de 10.000 linhas. Normalmente chegamos a esses casos por heurística para escolher quais testes fazer, como a ideia de se testar caso base, caso x, caso x+1 e exceção. As estratégias que comumente ajudam a melhorar uma base de testes poluída são: - Propósito bem definido para os testes, assim evitando que um certo aspecto seja desnecessariamente testado ou retestado. - Boas heurísticas para definição de teste, testar os casos base, caso x, caso x+1 e de exceções é suficiente quase sempre. - Redesign do componente em questão, se é necessário testar muitos casos, pode ser interessante refatorar, simplificar e quebrar as entidades para que tenham um conjunto de casos mais simples e definidos (código simples costuma ser o melhor código)
E assim ... dessas poucas formas podemos ter falsas garantias em uma dupla do mal com a mais código para ler, manter e se preocupar. Bora não ter mais coisas pra dar trabalho, seu psicólogo agradece.
Quando isso pode acontecer comigo?
Porque essas coisas terríveis acontecem com as pobres pessoas da TI? Na minha opinião de quem queria trabalhar menos, o mal uso costuma ser a teoria em desencontro com a realidade, somente com conhecimento de ambos nos termos reais condições de analisar o que está sendo feito ao invés de simplesmente fazer. São muitas as formas essa tristeza de desencontro podem ocorrer:
- Entendimento pouco robusto sobre a teoria por detrás dos testes automatizados e seus diferentes tipos, não basta entender como usar as bibliotecas de teste.
- Revisões de códigos pobres, as causas para isso podem ser muitas mas geralmente giram em torno da má compreensão do que está sendo feito e falhas de comunicação.
- Foco cego em métricas de testes. Por exemplo, a cobertura de testes deveria ser um guia e não uma regra, os testes são importantes demais para não se ponderar sempre.
- O código de testes precisa ser mantido com um grau de exigência ao menos parecido ao do código de produção. O código dos testes automatizados precisam ser lidos, corrigidos e executados.
- Pular ou comentar um teste deve ser considerado como um aviso, pois estaremos sujeitos a ausência da garantia colocada por ele ou talvez não precisamos dele se a ausência dele não for sentida. - Entendimento ruim do produto. É difícil perceber se temos as garantias corretas, nos levando a testar: - as entidades errados - os características errados - ou ainda criar um teste que verifica somente passa quando o código tá errado (um teste reverso)
Convite
Science is a systematic endeavor that builds and organizes knowledge in the form of testable explanations and predictions about the universe.
A ciência é um esforço sistemático que constrói e organiza o conhecimento na forma de explicações e previsões testáveis sobre o universo.
Algo deixa de ter algum valor científico e passa a virar uma crença quando não precisamos testar e tentar invalidar esse conhecimento. Experimente e tente falsiar tudo aquilo que precisa estar mais próximo de explicar a realidade como a ciência faz. E para os caóticos por natureza, tragam esse tópico para a empresa e assista :)
Latest comments (0)