Nota: O seguinte artigo irá ajudá-lo com: Desenvolvimento orientado a testes pode ser mais falado do que praticado
Existem algumas boas razões pelas quais o desenvolvimento orientado a testes não é tão amplamente utilizado quanto é discutido.
Todo mundo está falando sobre desenvolvimento orientado a testes. Alguém está realmente fazendo isso?
O TDD tem sido adotado pela classe de desenvolvedores em mídias sociais e painéis de conferências de tecnologia há vários anos como uma “melhor prática” de desenvolvimento ágil. Mas em uma conversa com o CEO da Diffblue, Mathew Lodge, ex-vice-presidente sênior da loja Python Anaconda, comecei a me perguntar se toda essa conversa está se traduzindo em ação.
Diffblue usa IA para automatizar a escrita de testes de unidade Java. Em um mundo perfeito, a Capa da Diffblue, disponível para teste gratuitamente, seria usada para complementar o TDD, mas não vivemos nesse mundo perfeito. Deixe-me explicar por quê.
Testando teoria e prática
TDD parece ótimo: Em teoria. Em sua forma mais pura, os desenvolvedores escrevem um teste primeiro projetado para falhar e depois escrevem o código. A ideia é que os testes sejam a expressão do que o código deve fazer, então você escreve o código para passar nos testes.
Isso geralmente será um processo iterativo, começando com requisitos mínimos, escrevendo testes, escrevendo código e, em seguida, expandindo e refinando gradualmente os requisitos nos testes e o código em pequenas etapas – refatorando o código à medida que novos modos de falha são descobertos ou novos recursos exigem .
VEJA: Kit de contratação: Desenvolvedor Back-end (TechRepublic Premium)
No mundo real, ninguém escreve uma descrição completa e completa do que o código deve fazer, disse Lodge. Por definição, a computação ágil tem tudo a ver com iteração – melhorias de código incrementais e frequentes para alcançar um resultado desejado. Como, de um modo geral, ninguém sabe exatamente como deseja que o código se comporte com antecedência, desenvolvedores astutos escrevem testes antes de se comprometerem com integração contínua e pipelines de entrega contínua como CircleCI, GoCD ou Travis CI.
Além disso, o desenvolvedor não sabe qual é a API para essa coisa porque ainda não a escreveu. A implementação informa a API, e todo desenvolvedor sabe como é muito difícil acertar a API na primeira vez. Então, como o desenvolvedor escreve testes primeiro?
Não é diferente das ferramentas emergentes de geração de código de IA, como o Co-Pilot. A princípio, as pessoas ficam surpresas ao vê-lo escrever código utilizável, como que magicamente. Mas quando se trata de produção, os melhores praticantes podem obter 30% do código criado pelo Co-Pilot, enquanto a maioria ainda deve ser escrita manualmente. Por quê? Ninguém pode descrever de forma completa e precisa qualquer software complicado que deseja com antecedência.
Mas, neste caso, isso é uma melhoria para os desenvolvedores e substancial. Só porque o Co-Pilot não pode gerar 100% do código final não significa que ele falhou. É progresso: qualquer coisa que libere mais tempo do desenvolvedor é uma coisa boa.
Mas, novamente, conversando com Lodge, parece que o TDD falha nesse teste básico. Para código greenfield, às vezes pode fazer sentido. Mas é tão difícil adotar como uma prática recomendada universal em ambientes de produção reais.
VEJA: Kit de contratação: desenvolvedor Python (TechRepublic Premium)
A Diffblue descobriu esse pequeno segredo sujo em uma pesquisa não relacionada a desenvolvedores corporativos em 2020, disse Lodge.
Embora o TDD seja popular, poucas lojas o praticam: uma pesquisa com desenvolvedores publicada em setembro de 2020 descobriu que, embora 41% dos entrevistados tenham dito que suas organizações adotaram totalmente o TDD, apenas 8% disseram que escrevem testes antes do código pelo menos 80% do tempo , que é a definição de TDD.
Dada a escolha de escrever testes ou código primeiro, parece que os desenvolvedores quase sempre vão se inclinar para o último, não importa o que os melhores profissionais digam. Os desenvolvedores são pessoas adoráveis que gostam de discutir e defender suas próprias causas favoritas, mas no final, os melhores desenvolvedores são práticos. Eles preferem fazer as coisas. O TDD não está morto, mas talvez não esteja tão “vivo” quanto às vezes pensamos.
Divulgação: Eu trabalho para o MongoDB, mas as opiniões aqui expressas são minhas.
