Like A Girl

Pushing the conversation on gender equality.

Code Like A Girl

Por que desenvolvedores devem escrever testes?

Mesmo com o amadurecimento dos processos de desenvolvimento, o que presenciamos é que dia após dia, ano após ano, a grande maioria dos projetos de software tem qualidade muito mais baixa do que o esperado, custo maior que o orçado e a entrega muito após o planejado.

Photo by Paul Esch-Laurent on Unsplash

Parte disso se deve muito ao fato de tentarmos incorporar qualidade no processo após o início do projeto. Todos nós desenvolvedores sabemos que no começo de um projeto é muito fácil progredir rapidamente. No entanto, à medida que o código começa a crescer, fica cada vez mais difícil adicionar novas funcionalidades e fazer alterações sem quebrar o que já existe.

Equipes responsáveis pela qualidade do produto estão cada vez mais presentes nas organizações. Entretanto, é humanamente impossível para essas equipes garantir que as milhares de linhas de código sejam retestadas manualmente a cada nova funcionalidade inserida na aplicação.

Pense que a grande maioria do código que você escreve não é voltada para o usuário, o que significa que muito do seu código não está diretamente relacionado à interface da aplicação. O seu código, em grande parte, é usado por outro código.

Mesmo que esses inúmeros pedaços de código não sejam necessariamente consumidos por humanos, eles são o alicerce para a construção da interface. E adicionar qualidade nesse tipo código é o que garante o diferencial.

Mas como garantir qualidade em estruturas tão fundamentais? Testes unitários, é claro. Ter uma boa base de testes unitários é a escolha certa para garantir que essa camada de código funcione.

Um teste unitário é um teste com enfoque em um comportamento isolado de um pequeno trecho de código. Normalmente são escritos na mesma linguagem que o software está sendo desenvolvido e são feitos pelo próprio desenvolvedor.

A criação e execução de testes unitários, deve fazer parte da rotina de todo bom programador. Todo código criado deve ter, em paralelo, a criação de testes. Você deve codificar um pouco, testar um pouco e vice-versa. Isso lhe dará segurança de que o que já existia ainda funciona.

O tempo despendido na criação de um teste será compensado em qualidade e estabilidade do software, ou seja, no tempo que não será perdido procurando e consertando bugs. Além disso, à medida que o produto cresce, sua capacidade de fazer mudanças rapidamente e com confiança não será afetada.

Acho que é um consenso entre os programadores que

é uma tarefa horrível trabalhar em um produto frágil, no qual as pessoas relutam em tocar, com medo de quebrar as relações misteriosas que fazem aquele código funcionar.

E o que é pior: como desenvolvedor é impossível afirmar o que está funcionando e o que parou de funcionar após qualquer mudança, mesmo pequena, no código da sua aplicação.

Quando você possui testes unitários você consegue detectar de forma rápida, automática e com pouco esforço o que parou de funcionar. E o melhor de tudo é que o teste unitário consegue informar a localização exata do erro, inclusive a linha que o problema ocorre. É um belo investimento, não acham?

É óbvio que os testes unitários não substituem outras formas de automação de testes e nem o teste de uma equipe humana. No entanto, com uma boa base de testes unitários, os esforços dos outros tipos de teste são muito mais eficazes, já que quando o código vai para o controle de qualidade não está repleto de bugs no nível de unidade.

Siga a tag codelikeagirlBR para ver nossos posts! 😀

Quer escrever ou traduzir artigos em português para a Code Like A Girl? Se você já faz parte do time de escritoras(es) da Code Like A Girl basta enviar seu artigo diretamente para nossa publicação. Se você ainda não faz parte do nosso time, envie uma mensagem direta para a conta de twitter CodeLikeAGirlBr ou um email para brazil@codelikeagirl.io. Nós avaliaremos seu artigo e ajudaremos a refiná-lo para publicação.