O que é o TDD?
No contexto de um negócio, o objetivo do software é agregar valor a esse negócio. Por causa disso, um dos principais desafios de qualquer esforço de desenvolvimento é o mapeamento dos requisitos e objetivos de negócios em requisitos de sistema correspondentes. Depois disso, a questão torna-se: Como escrever software para cumprir estes requisitos, e à medida que o seu projeto e a sua base de código crescem, como garantir que o seu software continua a cumprir estes requisitosEntre em Desenvolvimento Orientado a Teste.
O Desenvolvimento Orientado a Testes, ou TDD, é uma metodologia organizacional para escrever software escrevendo testes que descrevem e exercem esse software. No seu núcleo, o TDD é uma repetição de três passos: Escrever um teste falhado, fazê-lo passar, refatorar.
A noção é que começamos com um teste que descreve uma funcionalidade para qualquer recurso de software que esteja sendo desenvolvido. Executar esse teste pela primeira vez deve produzir uma falha, porque o código que está sendo testado ainda não foi escrito. Naturalmente, o próximo passo é implementar o recurso, com o objetivo de fazer o teste original passar. O terceiro, e provavelmente o passo mais importante do ciclo de vida, é então refatorar o código.
Escrever software é desafiador não só por causa de suas qualidades intrínsecas, mas também por causa de sua natureza dinâmica. Os requisitos comerciais podem mudar constantemente e, como resultado, os requisitos de software precisam ser capazes de se adaptar. O código que está escrito hoje vai atender às necessidades de hoje, mas amanhã, ou um mês a partir de amanhã, algo vai mudar, e como resultado, o código de hoje pode não ser mais a melhor maneira de resolver um problema em particular. Introduzindo um mecanismo para comparar o que o software é fazendo um registo do que o software deveria agora temos uma ferramenta poderosa que nos permitirá destruir, reescrever e religar o nosso código para melhor atender aos requisitos atuais, porque podemos ter certeza de que, enquanto todos os nossos testes passarem, a saída do sistema deve ser a mesma.
Por que devemos usar o TDD?
Uma revisão de 2014 realizada pela Universidade de Helsínquia descobriu que, em muitos casos, o TDD produziu efeitos positivos em termos de defeitos, qualidade, complexidade e manutenção, mas que essas melhorias podem custar o aumento dos esforços de desenvolvimento. Esta não é uma conclusão surpreendente, dado que escrever testes adicionais exigirá esforços adicionais – mas o que os estudos desta natureza parecem deixar de lado é o benefício chave do TDD, que é o feedback.
Fechar o ciclo de feedback significa reduzir o tempo necessário para fazer uma mudança e aprender algo. Quanto mais rápido você puder fazer isso, mais ágil você pode ser. A maioria das métricas que tentam quantificar a produtividade do desenvolvimento relacionam-se com unidades de trabalho ao longo do tempo, e ao reduzir o tempo necessário para receber feedback acionável, o TDD permite um uso mais eficiente desse precioso recurso. Diz-se que o tempo é dinheiro, por isso o benefício económico aqui é evidente. Se você já ouviu alguém mencionar uma mudança para a esquerda no contexto do ciclo de vida do desenvolvimento de software, é exatamente a isso que eles estão se referindo.
Um benefício adicional para ter um conjunto de testes para a sua aplicação é que você pode automatizar isso. Os desenvolvedores não só podem executar esses testes como parte do ciclo de vida do desenvolvimento, mas também podem ser executados por outros sistemas como parte de testes de fumaça ou de um pipeline de CI/CD . Ao automatizar as etapas para entregar código ao mercado, permite uma entrega mais rápida do produto como um todo, o que, por sua vez, acelera o feedback que você pode receber dos usuários, que pode ser interpretado e aplicado à próxima iteração.
Os efeitos sinérgicos destes dois pontos são claros: Com uma base de código que permite aos programadores adaptar continuamente a base de código às necessidades do negócio, e a capacidade para o negócio solicitar rapidamente feedback dos seus clientes, o resultado é um sistema que permite às equipas entregar mais valor a partir de menos trabalho.
Tirar o máximo partido do TDD
O desenvolvimento orientado a testes é apenas uma das muitas abordagens diferentes para testar software. A parte importante, independentemente de como escolherem implementá-lo, é que ele dá valor à vossa organização. Como qualquer outra disciplina, vocês devem sentir-se à vontade para usá-la, adaptá-la como achar conveniente, ou não usá-la de todo, com base inteiramente nas necessidades da sua organização. Dito isto, se escolherem percorrer o caminho do TDD, como o profeta Clapton predisse: “É da maneira que o usam.”
Como qualquer outra ferramenta, a eficácia e o valor do TDD dependem da sua implementação. Muitas vezes, no desenvolvimento de software, várias ferramentas ou técnicas são transformadas em bodes expiatórios para explicar as falhas ou falhas de um projeto, mas é um pobre artesão que culpa as suas ferramentas. Então, vamos focar em como tirar o máximo proveito do TDD.
Refatoração Cultural
O último e mais importante passo do TDD é refatorar o código, mas para o TDD funcionar, isso provavelmente não é a única refatoração que precisa acontecer. Se optar por implementar alguma forma de Desenvolvimento Orientado a Teste, é importante que a cultura circundante também se adapte para apoiar este estilo de filosofia de desenvolvimento.
No caso do TDD, a falha mais comum tende a ser que o ciclo contínuo de testes de escrita, fazendo-os passar, e então a refatoração nunca é realmente concluída, mas antes é curto-circuito ao saltar sobre a etapa de refatoração. Na maioria das vezes, o problema não é TDD, ou qualquer outra técnica específica, mas sim a própria cultura em que o software é desenvolvido.
Não ao contrário da documentação, a refatoração parece ser uma das primeiras coisas lançadas ao mar quando prazos ou orçamentos se estribam porque afinal, alguém tem que escrever todos esses testes. E assim segue-se que, durante o tempo de crise, os testes e a documentação, e qualquer outra coisa que não seja considerada crítica de missão são descarrilado. O que invariavelmente se segue é um declínio constante na qualidade global da base de código e, no seu lugar, uma acumulação de dívida técnica.
Refatoração é o passo do processo que se esforça para transformar código que simplesmente funciona em uma base de código que é mais limpa e sustentável. É a parte que permite aos desenvolvedores dar um passo atrás e reconhecer padrões dentro do sistema geral e tomar decisões mais bem informadas sobre como eles podem ser adaptados para serem mais versáteis ou reconhecer anti-padrões emergentes e tomar medidas para mitigá-los. Pode até ser a diferença entre reconhecer quando é hora de dividir a arquitetura geral em microsserviços discretos ou qualquer outro de uma miríade de possíveis melhorias. Sem este passo, você pode perder oportunidades de introspeção e melhoria incremental, e, em última análise, sua base de código arrisca uma transformação gradual (ou não) em uma grande bola de lama.
Para colher os benefícios do Desenvolvimento Orientado a Teste, é importante que a cultura tenha uma visão longa do processo como um todo, e seu potencial, e investir o tempo na aplicação do ciclo completo de “vermelho, verde, refatoração”, e não apenas os bits que são convenientes.
Brinquedos novos brilhantes
Quando se trata de design do sistema como um todo, muitas vezes é gasto muito tempo a planear as especificidades de um sistema sem realmente escrever nenhum código. Um projeto de “campo verde” pode ser excitante, com todo o potencial antecipatório associado a uma folha de papel limpa. Engenheiros e arquitetos também são vítimas da tentativa-esta-itis, onde defendem o uso de uma tecnologia de sabor do mês, ignorando qualquer um dos sinais de alerta de que pode não ser uma boa opção para este projeto em particular em favor da oportunidade de experimentar algo novo ou fresco. Avançamos uns meses e o framework-du-jour já não está a satisfazer as necessidades da equipa, a qualidade do código está a sofrer, e estamos de volta à parte em que a tecnologia se torna o bode expiatório para o mau resultado do projeto.
No final do dia, o que é importante é que a tecnologia, metodologia ou estrutura usada para facilitar o TDD funciona para a equipe e para o negócio. Se você é prejudicada pelas suas ferramentas, não só elas não estão agregando valor, mas estão trabalhando ativamente contra você. Tome cuidado ao avaliar cuidadosamente qualquer estrutura que você pretende usar, e tire um tempo para entender exatamente como você vai usá-lo. Esta abordagem é válida para todas as decisões de design, não apenas para as relacionadas com TDD!
Embrulhar
Em poucas palavras, a ideia de algo como TDD é fornecer uma estrutura para recolher feedback de uma forma mais conveniente e não simplesmente uma técnica para impedir que os erros apareçam na sua base de código. Seja qual for a abordagem que escolher, a chave deve ser que ela permita que o seu negócio e o seu software se adaptem mais rapidamente às tendências em mudança e às necessidades do negócio. Ao longo do caminho, tenha em mente que o TDD e os seus homólogos não são simplesmente algo que pode pedir à sua equipa de desenvolvimento para implementar e depois esquecer, e que, para aproveitar eficazmente estas técnicas, deve-se ter cuidado para abraçar e permitir a abordagem a um nível cultural antes de mergulhar em detalhes de implementação, como estruturas e ferramentas.
