Se não conhece o TDD, Test-Driven Development, recomendo que leia o livro escrito por Kent Beck: Test Driven Development: By Example!
Mas para quem já conhece, é muito comum ouvir falar que esta forma de desenvolver software está relacionada apenas ao Back-end. Mas será que isso é verdade? Não podemos aplicar também no front-end? Se sim quais são as vantagens? Vamos entender isso ao decorrer do artigo. Vamos lá! 🚀
Testar é importante!
Primeiro gostaria de confessar que antes, nunca tive vontade de realizar os testes no front-end. Parecia que era uma perda de tempo. Afinal quando eu comentava sobre testes alguns diziam: " Isso é perda de tempo, ainda mais do lado do client, precisamos que você se concentre em fazer funcionar essa feature!". Nesse caso, estava naquela época tentando resolver um problema de um componente que tinha uma funcionalidade que parecia bem simples, mas existia um bug que ninguém estava entendendo o porque ocorria. A solução que foi adotada na época foi "camuflar" o bug. Nada profissional. Depois de um tempo, consegui resolver. Mas sempre me perguntava se isso realmente precisava ter ocorrido. Como poderíamos nos prevenir? Tenho estudado muito nesses últimos 3 anos sobre boas práticas, Arquitetura Limpa, Código Limpo entre outros princípios como os que constituem S.O.L.I.D. Mas quando estudei TDD pela primeira vez reparei como ela facilita a implementação dos testes. Esta técnica nos ajuda muito a pensar com clareza no que realmente aquela função precisa fazer. Test Driven Development nos obriga a primeiro realizar o teste e depois realmente partir para a implementação do método ou função.
Os testes ajudam a manter um código limpo e o TDD entra exatamente nesse ponto, independente de estarmos trabalhando no backend ou frontend. Você vai começar a pensar em funções e métodos pequenos que contém apenas responsabilidades que dizem ao seu contexto. Já que a maioria dos desenvolvedores não cresceu com o desenvolvimento guiado por testes em mente, parece um absurdo essa técnica. Por que escrever os testes primeiro quando não há código para começar?
Normalmente pensamos no que o código deve fazer, escrevemos o código na IDE e então assumimos que funciona. Escrever testes tira esses pensamentos iniciais de nossas mentes e os coloca em uma forma que é mais concreta. Além disso você pode esquecer de alguma regra importante. Por isso é bom testar todos os comportamentos possíveis do seu método.
Vamos lembrar rapidamente as três fases do Desenvolvimento Orientado a Testes.
As três fases do TDD
O processo do Test-driven Development se baseia na repetição de um ciclo de desenvolvimento e testes em 3 fases, que podemos chamar de: fase vermelha, verde e refactoring.
Na primeira fase, você escreverá um teste unitário que quando executado irá falhar, pois a lógica ainda não existe.
Na fase verde, é hora de codar, ou seja, criar um código que passe no teste unitário recém escrito.
Na fase de refatoração do código, o desenvolvedor deve focar na melhoria da leitura do código, removendo redundâncias e adotando boas práticas conforme for necessário.
O ciclo do TDD nos ajuda a projetar um código mais limpo e nos motiva a sempre limpar nosso código. Estamos SEMPRE atrelados a este ciclo de testes e refactoring.
É preciso paciência!
Iniciar o desenvolvimento orientado a testes pode ser um caminho com muitos aprendizados e erros. Muitos acham que a curva de aprendizagem é curta e engana-se quem pensa dessa maneira. Principalmente se o programador trabalhou vários anos sem nunca ter lido ou praticado TDD. Além disso, muitos que estão iniciando tentam colocar em prática a técnica em código já existente. Não é esse o conceito do desenvolvimento orientado a testes. A principal característica do TDD é que ele seja orientado a testes. Primeiro criamos o teste depois desenvolvemos a funcionalidade.
Outro fator é que leva tempo para entender e trabalhar com a técnica da melhor maneira possível. O TDD na verdade desacelera a produção de novas funcionalidades no inicio, principalmente em equipes com pouca experiência profissional. Se leva um tempo até todos da equipe se adaptem a técnica. Ninguém vai chegar em uma semana ou mês e dizer que é especialista em TDD. Principalmente em nossa área onde a tecnologia, ferramentas e métodos estão sempre em frequente mudança!
Mais um fato. Em algumas empresas o foco é entregar o software independente se o código é legível ou não. Conheço muitos desenvolvedores que trabalharam em várias empresas diferentes e segmentos de negócios distintos. Segundo eles a falta de colaboração da própria equipe, gestores, coordenadores e clientes gerava um estresse muito grande para manter os testes. A falta de planejamento em organizar o front-end e definir bem seus componentes também prejudicava o andamento de se aplicar TDD dentro dessas empresas.
Por isso é importante ter paciência e continuar aplicando a técnica a medida que seu projeto cresce. Existem muitos fatores que podem atrapalhar, mas cabe também a nós o esforço e continuar a manter o desenvolvimento orientado a testes. Não desanime!
Vantagens
Vou listar apenas 4 vantagens para não ficar muito longo este artigo. Veja como toda a equipe pode se beneficiar do TDD:
Planejar e pensar melhor: Planejar e pensar é parte essencial do trabalho de todo desenvolvedor. Ao orientar o desenvolvimento aos testes, acaba-se pensando e planejando melhor a implementação de acordo com as especificações.
Se ganha tempo: Provavelmente todos nós já ouvimos ou falamos a famosa frase: "Já finalizei o desenvolvimento das funcionalidades novas. Só falta finalizar os testes, é rapidinho... ".
Pobre Dev... em primeiro lugar ainda não finalizou a feature, pois não garantiu se ela funciona corretamente. E segundo, lá se vão algumas horas apenas escrevendo testes. Sabe a pior parte? É que isso acaba frustrando o desenvolvedor e ele acaba odiando eternamente testes, assim como eu odiava antes 😂. Quando se coloca em prática o TDD, teste e implementação acabam sendo escritos mais rapidamente.
Depuração se torna mais simples: o processo de depuração se torna mais intuitivo, principalmente no front-end. Quando um teste falha, é mais fácil identificar onde se encontra o problema. Afinal se o teste informa que era esperado um valor mas recebeu null, isso ajuda bastante!
Confiabilidade: Por estar passando por testes de validação, o código se torna mais confiável e menos propenso a bugs. Se você está testando as validações de um input, vai poder cobrir todas as possibilidades e evitar que alguma regra seja esquecida.
Adicione testes à medida que adiciona novas regras
Imagine que precisa criar um campo de entrada (input) e um botão. O valor do botão deve estar entre 1 e 100 e queremos verificar se o botão se comporta corretamente. Primeiro, escrevemos um teste para verificar se o valor estiver entre 1 e 100, o botão está habilitado. O teste deve falhar, pois não implementamos a lógica e então devemos desenvolver um campo de entrada e um botão. Depois disso, escrevemos outro caso de teste sobre os valores que estão abaixo de 1. O botão deve ser desabilitado para esses valores. O teste falhará porque não implementamos algo assim. Voltamos e implementamos essa lógica. Voltamos e executamos os testes e todos devem passar. Depois, continuamos a escrever os outros testes para valores acima de 100 e repetimos esse processo até o final. Claramente vai perceber que seu raciocínio ao desenvolver vai ficar mais apurado, pois automaticamente também temos que testar as situações que são invalidas para a lógica. Além disso entendemos bem as responsabilidades de cada método dentro daquele componente.
Vale a pena o TDD no Front-end?
A resposta é sim! Mas exige um esforço e disciplina que devem ser levados a sério. Não adianta nada iniciar com boas práticas o front-end e ir abandonando aos poucos conforme a demanda aumenta. Isso vale também para o TDD. Se a equipe não entende bem como iniciar ou se a "cultura" da empresa é de desenvolver aplicações que morrem depois do projeto ser entregue, será bem frustrante tentar implementar. Mas lembre-se que ter a atitude em aplicar essa técnica mesmo que outros não apliquem, faz você ganhar muito em conhecimento e até evitar que as funcionalidades que você desenvolve causem bugs em produção! Por isso incentivo sim a colocar em prática tanto em ambientes de estudo e principalmente corporativos.
Lembre-se dessa frase:
"O TDD é uma disciplina, e isso significa que não é algo que vem naturalmente; como muitas das recompensas não são imediatas, mas vêm apenas a longo prazo, você precisa se forçar a fazê-lo no momento. " - Harry Percival autor do livro Desenvolvimento Orientado a Testes com Python.
Conclusão
Vimos que podem existir desafios, mas as vantagens são muitas. Em próximos artigos espero trazer exemplos mais mão na massa, para deixar bem claro como podemos nos beneficiar no front-end e melhorar cada vez mais nossas aplicações.
Fico por aqui neste post! Obrigado por ler! 😄