A transformação digital aumentou consideravelmente a demanda por softwares dos mais diversos tipos. Aliado às tecnologias cada vez mais robustas, esse aumento exige estratégias tanto para otimizar o desenvolvimento quanto para garantir softwares funcionais e com poucos problemas.
Como já sabemos, a qualidade de um programa não é medida com um produto já feito. Sendo assim, é importante que as otimizações sejam implementadas desde as primeiras linhas de código, com os testes unitários.
Com a aplicação do TDD — Test-Driven Development ou Desenvolvimento Orientado por Teste, em português —, os desenvolvedores podem, desde os inícios dos trabalhos, identificar as falhas no fluxo de informação, reparando os erros básicos que interferem no resultado.
Neste post, trazemos um guia completo sobre testes unitários. Vamos mostrar o que são, para que servem e por que se tonaram uma tendência no mundo da programação. Além disso, vamos explicar o motivo de muitos profissionais serem resistentes aos testes, bem como maneiras de automatizá-los e os benefícios que geram. Boa leitura!
O que um teste unitário?
Trata-se da verificação da menor parte testável de um software — dependendo da linguagem de programação, como PHP, Java, Python, JavaScript etc. Se o código for desenvolvido em uma linguagem que suporta um paradigma funcional, por exemplo, a menor parte será qualquer função. Já se tiver base na orientação a objetos, será um método de seu objeto.
O Foco deve ser a garantia de conformidade para que, quando for necessário fazer alterações em um código, seja por motivos de manutenção ou atualização, essas alterações não provoquem outros problemas, gerando uma reação em cadeia.
Para que servem?
Existem outras formas de testar a funcionalidade de um código, com ferramentas que aparentemente são mais rápidas. Se eu posso simplesmente verificar se meu código está funcionando, por que deveria escrever um outro para testar um já existente? E mais, como garantir que o segundo está em pleno funcionamento?
Assim como qualquer outro teste, os unitários não servem apenas para que verifiquemos a atuação de uma função, mas para garantir que ela permaneça sendo bem-executada, mesmo que haja a necessidade de alteração em sua base de código. Não é incomum para os programadores ter que corrigir problemas criados por outras resoluções ou após uma implementação que gerou uma “bola de neve”.
Nada mais frustrante do que ter que consertar um erro que foi gerado após a solução de outro. Isso gera um looping de manutenções de código que pode durar semanas, sendo que muitas empresas têm uma equipe apenas para tratar dessas correções.
Por que fazê-los?
Pode não parecer a melhor opção escrever testes para uma função que você acabou de elaborar. Esse tipo de pensamento nasce de uma impressão de que faremos o mesmo trabalho duas vezes, afinal é bastante provável que você passe mais tempo programando os testes de uma função do que desenvolvendo o código em si.
No entanto, é importante que você tenha em mente que a manutenção é o que demanda mais esforços quando se trabalha com códigos. Não se esqueça de que eles terão uma centena de funções sendo executadas, ou seja, com o tempo, sua base de código ficará enorme e será impossível testar de forma manual a cada alteração. Com os testes unitários, em poucos segundos, toda a aplicação será testada.
Solucione problemas recorrentes
Quando o desenvolvedor adota os testes unitários em sua trabalho, ele passa a ter a possibilidade de solucionar dois problemas bastante comuns que atrapalham o bom desempenho de um software. São eles:
- alto índice de bugs — quando há erros recorrentes no funcionamento da aplicação que podem tornar o software inutilizável;
- degeneração com o uso — acontece quando o programa, após a implementação, apresenta um excelente desempenho e, conforme o tempo vai passando, começa a apresentar algumas complicações as quais exigem a substituição de todo o sistema.
A execução de pequenos de testes pode identificar as barreiras que afetam o bom desempenho já na raiz. Isso porque os testes unitários potencializam a validação de todas as funções de um software, o que resulta na diminuição da margem de erros futuros. Além disso, eles ajudam na simplificação do código, permitindo a eliminação de trechos desnecessários que tornam o programa mais pesado e com baixo desempenho.
Além disso, quando o gestor padroniza essas avaliações, garante que o trabalho em equipe seja mais fluido, reduzindo o risco de sobrecargas por excesso de manutenções, e também permite entregas mais certeiras, dando a segurança para que o produto entregue esteja já com todos os erros solucionados, aumentando a durabilidade e aprimorando a qualidade da nova aplicação.
Por que o TDD se tornou uma tendência no mundo do desenvolvimento?
O Desenvolvimento Orientado por Testes, como o próprio nome sugere, trata-se de uma mudança na cultura organizacional e na equipe de desenvolvimento, a qual coloca os testes como base para a criação das aplicações, os quais são escritos antes do código de produção.
O TDD é baseado em pequenos ciclos, ou seja, para cada funcionalidade do código, é criado um teste. Como é criado antes, em um primeiro momento, o teste falha, pois a funcionalidade para a qual ele foi criado ainda não está pronta. Assim que a funcionalidade é criada, ele passa.
Porém, precisamos entender que não podemos sair escrevendo outro teste só porque já temos um passando. É importante que essa nova funcionalidade seja refatorada, ou seja, precisará ser alinhada aos padrões de boas práticas para o desenvolvimento de software. São essas adaptações que delimitarão o código final, mais limpo, menos acoplado e mais fácil de fazer a manutenção.
Como funciona o ciclo de desenvolvimento Red, Green, Refactor?
Para criar uma cultura de direcionamento por testes, é importante que o desenvolvedor adote alguns padrões a fim de que haja conformidade. Um dele é o ciclo de desenvolvimento Red, Green, Refactor, que funciona da seguinte forma:
- Red — o desenvolvedor cria um teste que inicialmente não passará;
- ele adiciona a nova funcionalidade ao código;
- Green — o teste passa;
- Refactor — é feita a refatoração do código;
- passa para o próximo teste.
Esse tipo de estratégia promove um feedback rápido sobre essa nova funcionalidade, além de dar um retorno sobre a possível quebra de outras funcionalidades do sistema. Dessa forma, o desenvolvedor ganha muito mais segurança para fazer as refatorações e para adicionar funcionalidades.
Quais os principais motivos para aplicar TDD?
É possível ter diversos ganhos com essa estratégia de desenvolvimento. Entre elas, podemos destacar:
- fornece um feedback mais rápido sobre a nova funcionalidade e as demais de um sistema;
- contribui para um desenvolvimento padronizado, com código mais limpo e otimizado;
- entrega uma maior segurança no refactoring, pois o desenvolvedor pode ver o que está ou não afetando sua atuação;
- entrega uma maior segurança na correção de bugs;
- melhora a produtividade, pois, ao encontrar menos bugs, há um desperdício menor de tempo com depuradores;
- o código da aplicação se torna mais flexível, pois, ao escrevermos os testes, temos que separá-lo em pequenos pedaços, o que significa que ele estará menos acoplado.
Mais para frente, falaremos de forma mais detalhada quais são os principais benefícios da adoção do TDD em sua empresa, comparando com os principais motivos que levam a alguns desenvolvedores a ficarem reticentes quanto a essa nova tecnologia.
Quais são as principais etapas de um teste?
Em primeiro lugar, precisamos ter em mente que teremos que fazer o processo ao contrário do tradicional. Isso significa que devemos testar e codificar e não o contrário. Pode parecer estranho em um primeiro momento, mas, no final, você verá que faz sentido.
O motivo de fazermos primeiramente o teste e depois o código é a garantia de que daremos os passos mais simples para que seja feita a codificação da funcionalidade — seremos “obrigados” a criar a funcionalidade mais simples possível para passar o teste.
No início, essa técnica pode não parecer a mais intuitiva e o gráfico de aprendizado pode não estar entre os melhores. No entanto, conforme você aprimora a técnica, verá que é a maneira mais simples e intuitiva de desenvolver.
Crie o primeiro teste
Quando acabamos de escrever o teste e ainda não fizemos a implementação da funcionalidade, ele falhará, isso é certo. Isso acontece porque ele espera uma resposta a algo que ainda não está pronto. Com esse teste em nossa frente, temos apenas um objetivo: fazê-lo passar. Isso nos leva à próxima fase, que é a implementação da nova funcionalidade.
Desenvolva uma nova funcionalidade
Já falamos e vamos ressaltar: o código deve ser escrito da forma mais simples possível, ficando limpo, simples e funcional. Por isso, nesse momento, devemos esquecer os Patterns, Boas Práticas, Inversão de controle etc. para otimizar o código de nossa funcionalidade.
Nesse momento, o objetivo é escrever alguma funcionalidade que faça o teste passar sem quebrar para que tenhamos mais segurança na refatoração desse código após alguns minutos. Não podemos esquecer o padrão de sequência de desenvolvimento:
- código que funciona → código simples e limpo → código rápido.
Com a nova funcionalidade implementada e o teste passando, devemos passar para a próxima fase.
Faça uma refatoração
Agora é o momento tão esperado pelos programadores que ficaram espantados quando dissemos, no tópico anterior, que não deveríamos nos preocupar com as boas práticas de desenvolvimento na implementação da funcionalidade. Podem ficar tranquilos, pois é na fase de refatoração que analisaremos com mais calma o código com o objetivo de passar no teste.
Este é o momento no qual você deverá retirar as duplicidades, extrair os métodos, renomear as variáveis, extrair classes, interfaces e utilizar um padrão de projeto relacionado à linguagem em questão. Aqui, deveremos deixar nosso código mais simples, claro e funcional.
A partir de agora, temos um teste que nos mostrará qualquer erro que ocorrer quando formos melhorar o código — não apenas o que acabamos de escrever. À medida que você estrutura os testes, criará uma suite em que poderá refatorar sem se preocupar com a danificação de um código sempre que for fazer alguma alteração, pois já terá os testes capazes de indicar qualquer falha.
Mude o código de forma segura
No último tópico, falamos sobre a refatoração, que nada mais é do que a melhoria do código. Normalmente, isso já seria necessário, mas com o TDD se torna obrigatório — sempre que escrevemos um teste, devemos escrever uma funcionalidade testável, a qual não pode quebrar nenhuma outra. Se quebrarmos um teste, teremos que fazer um esforço para que o código não esteja muito acoplado ao seguinte.
Boa parte dos desenvolvedores ainda escreve com foco nas modificações futuras. Ao desenvolver o código com Singleton, Factory, Template Method, Bridge, Strategy e outros, estão na verdade em busca de segurança, porém indo contra todos os princípios das metodologias ágeis.
É claro que a preocupação com mudanças que acontecerão com o passar do tempo faz parte do dia a dia de qualquer desenvolvedor. Entretanto, ele deveria acentuar a necessidade de criar um código limpo, simples, claro, testável e de fácil manutenção.
O que não pode acontecer é o desenvolvedor passar muito tempo imaginando um design que seria perfeito para a aplicação, mas gera um código maior do que o necessário. Ao adotar o TDD como método, abandonamos esse pensamento pela necessidade de ver o teste passar logo, ou seja, buscamos a simplicidade.
Como automatizar os testes?
Uma forma de agilizar os testes é automatizando-os com foco na priorização das avaliações mais comuns, ou seja, aquelas que se repetem com frequência todas as vezes que há a adição de um novo código. Há também a possibilidade de criar um GUI — Graphical User Interface ou Interface Gráfica do Usuário, em português — para otimizar o trabalho.
Veja abaixo uma lista com as estruturas, ferramentas e bibliotecas que auxiliam os desenvolvedores na automação de testes em diferentes linguagens de programação:
Por que muitos desenvolvedores ainda resistem a praticar o TDD?
Muitos desenvolvedores ainda estão receosos em relação à ideia da aplicação do TDD pela necessidade de ter que criar códigos extras para desenvolver cada funcionalidade. No entanto, essa é uma impressão equivocada. Todo desenvolvedor já teve que corrigir um bug no sistema e, como consequência, criou outros dois no lugar.
Essa é uma situação bastante frequente, o que faz com que muitas empresas tenham em seus quadros desenvolvedores apenas para solucionar problemas — em alguns casos, há a necessidade de reescrever o código, por estar “sujo” e sem padrão. Ou seja, no fim, o que seria uma economia de código, se torna um looping de não conformidades e retrabalhos. Veja abaixo alguns dos motivos para essa resistência.
Dificuldade para começar
Mesmo tendo uma extensa documentação, iniciar o TDD pode ser mais trabalhoso do que muitos desenvolvedores estão a fim de encarar. Isso acontece pelo fato de que, para economizar tempo, muitos deles tentam praticar o método em um código já existente, o que não é o caminho mais adequado.
A lógica de existir um desenvolvimento orientado por teste é que o código seja digitado somente após a criação deles. Isso pode ser difícil de entender em um primeiro momento, afinal se não temos nada para testar, por que testaremos?
Como os seres humanos têm a tendência inicial de rejeitar o que os tira da zona de conforto, o TDD tem encontrado mais resistência entre os desenvolvedores mais experientes. É fácil entendê-los, visto que, para quem já tem uma metodologia prática, a mudança pode parecer uma aventura.
Não podemos esquecer de que a tecnologia evolui cada vez mais rápido, com novas fermentas e métodos que se impõem como uma necessidade. O TDD é uma dessas tendências.
Curva de aprendizado mais lenta
Esse tópico é complementar ao anterior, pois é outro motivo que tem feito muitos desenvolvedores abandonarem a ideia de desenvolvimento orientado por testes. Como toda nova tecnologia, a prática do TDD leva tempo para ser absorvida, o que requer disponibilidade e empenho do programador. Um profissional pronto pode resistir nesse momento, mas certamente terá nos resultados o maior incentivador para continuar seu aprimoramento.
Pensam que gastarão mais tempo
Outro motivo pelo qual muitos programadores ficam reticentes com o TDD é o de deduzirem que, ao produzir os testes, tornarão a produção mais lenta. Contudo, essa maior produção de código será recompensada no fim com redução de retrabalho, entrega mais alinhada às necessidades dos clientes e códigos mais limpos.
Quais são os principais benefícios da TDD?
Nos tópicos acima, falamos sobre os principais motivos que fazem alguns desenvolvedores terem ressalvas em relação ao desenvolvimento orientado a testes. Veja a seguir os benefícios que esse modelo de desenvolvimento traz para quem o adota.
Melhora a qualidade do código
O TDD tem um princípio básico que diz: se algo não pode ser testado, é porque foi desenvolvido de forma errada. Pode parecer apelativo, mas não é. Um bom programador consegue, em pouco tempo, perceber as mudanças em sua forma de programar. O TDD ajuda no aprimoramento de seu código, que vai ganhando cada vez mais qualidade, com objetos concisos e com menos dependências.
Aprimora o raciocínio
Para tornar o código cada vez mais conciso, reduzindo a quantidade de acoplamentos e dependências, o desenvolvedor terá que aprimorar seu raciocínio lógico — o que se torna um exercício.
É um processo de melhoria contínua, que fará com que o desenvolvedor passa a olhar o seu código sempre buscando maneiras de otimizá-lo e com o tempo, isso se tornará um processo natural. Com o TDD, esse diferencial se torna uma obrigação, ou seja, ou o programador se aprimora ou não conseguirá prosseguir com os testes
Entrega uma maior segurança no desenvolvimento
Esse é um ponto importantíssimo nos dias de hoje. Não estamos falando de segurança da informação, mas do desenvolvimento. Por exemplo, um desenvolvedor criou um software há cerca de um ano. Como é normal para quem trabalha com desenvolvimento, é sempre difícil lembrar de todos os pontos de atenção relacionados ao código em questão.
Quando for implementada uma nova funcionalidade a esse código, é importante que ela seja minuciosamente testada para garantir que não atinja os demais módulos da aplicação. Fazer tudo isso manualmente após um ano é inviável, pois dificilmente o programador lembrará o que afeta o software.
Ao adotar a prática do TDD, ele saberá que cada pequena parte do código foi devidamente testada, ou seja, poderá realizar alterações sem medo mesmo após um ano.
Como cada funcionalidade, por menor que seja, já está testada, se for necessário fazer qualquer tipo de alteração, em poucos segundo será possível identificar que houve quebras e, principalmente, em que locais elas aconteceram. Tendo isso em mãos, fica muito mais fácil corrigi-las.
Melhora o trabalho em equipe
Por dar mais segurança ao desenvolvimento, o TDD torna o trabalho em equipe muito mais harmonioso, eliminando duvidas e discussões desnecessárias. Se é preciso trocar de desenvolvedores com um projeto em andamento, o novo programador só precisará entender qual task deverá ser realizada e fazer a leitura das features que já foram desenvolvidas.
A empresa não perde produtividade e pode trabalhar com equipes em mais de um turno, para garantir o cumprimento de prazos em tarefas mais complexas. Quando rodar os primeiros testes, já terá um panorama para entregar o trabalho com mais agilidade e segurança. Algumas empresas que atuam com o TDD permitem que o desenvolvedor tenha um entregável já em seus primeiros dias de trabalho. Sem os testes, o profissional teria que ganhar um tempo para se adaptar.
Como vimos neste post, os testes unitários dão a oportunidade para que os desenvolvedores aprimorem o código durante o desenvolvimento, tendo um resultado muito mais próximo do desejável do que seria no desenvolvimento em bloco. Quando o desenvolvedor opta pelo TDD, perde alguns minutos com a criação dos testes, mas ganha horas, dias ou até semanas em matéria de prevenção de erros e possíveis correções em uma nova implementação do que em um código feito sem testes.
Gostou de nosso guia completo sobre testes unitários? Então, assine já nossa newsletter e receba mais conteúdos ricos como este em primeira mão.
