Home Blogs Há mais para o desenvolvimento orientado a testes do que o QA
Applications

Há mais para o desenvolvimento orientado a testes do que o QA

About The Author

Outline

Muitos, se não a maioria, dentro do mundo do software passaram a pensar em Test-Driven Development (TDD) por pouco como um processo exclusivo para o desenvolvimento de software. Muitas discussões e debates têm se centrado no uso de ferramentas ou técnicas específicas destinadas a exercer cada canto do código contra uma lista predefinida de requisitos com o objetivo de demonstrar que uma determinada base de código funciona como descrito. Como acontece com muita frequência, torna-se difícil separar o sinal do ruído e do princípio da prática, e assim nos perdemos nos detalhes da implementação e perdemos de vista a intenção original. Portanto, vamos dar um passo atrás e tentar reconsiderar a conversa em torno do desenvolvimento orientado a testes: Especificamente, o que é isso e como ele pode ajudar seu negócio?

O que é TDD?

Dentro do contexto de um negócio, o objetivo do software é agregar valor a esse negócio. Por isso, 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 pergunta se torna: Como você escreve software para atender a esses requisitos, e à medida que seu projeto e sua base de código crescem, como você garante que seu software continue atendendo a esses requisitos

Entre em Desenvolvimento orientado a testes.

Desenvolvimento orientado por testes, ou TDD, é uma metodologia organizacional para escrever software escrevendo testes que descrevem e exercem esse software. Em seu núcleo, TDD é uma repetição de três etapas: Escrever um teste falhando, fazê-lo passar, refatorar.

A noção é que você começa com um teste que descreve um pedaço de funcionalidade para qualquer recurso de software que está 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 é então 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 de negócios 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 específico. Introduzindo um mecanismo para comparar o que o software é fazendo um registro do que o software deve estamos fazendo agora temos uma ferramenta poderosa que nos permitirá rasgar sem medo, reescrever e reconetar nosso código para melhor atender aos requisitos de hoje, 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 TDD?

Uma revisão de 2014 realizada pela Universidade de Helsinque descobriu que, em muitos casos, o TDD produziu efeitos positivos em termos de defeitos, qualidade, complexidade e manutenção, mas que essas melhorias podem vir ao custo de um aumento dos esforços de desenvolvimento. Esta não é uma conclusão surpreendente, uma vez que escrever testes adicionais exigirá esforços adicionais – mas que estudos desta natureza parecem deixar de fora é o benefício chave do TDD, que é o feedback.

Fechar o loop de feedback significa reduzir a quantidade de tempo que leva 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 se relaciona 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, então 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, isso é exatamente o que eles estão se referindo.

Um benefício adicional para ter um conjunto de testes para o seu aplicativo é que você pode automatizá-lo. 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 do teste de fumaça ou de um pipeline de CI/CD. Ao automatizar as etapas para entregar o código ao mercado, ele permite uma entrega mais rápida do produto como um todo, o que por sua vez agiliza o feedback que você pode receber dos usuários, que podem ser interpretados e aplicados à próxima iteração.

Os efeitos sinérgicos destes dois pontos são claros: com uma base de código que permite que os desenvolvedores adaptem continuamente a base de código às necessidades do negócio, e a capacidade para o negócio solicitar rapidamente feedback de seus clientes, o resultado é um sistema que permite que as equipes forneçam mais valor com 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, como você optar por implementá-la, é que ela agrega valor à sua organização. Como qualquer outra disciplina, você deve se sentir livre para usá-lo, adaptá-lo como você vê, ou não usá-lo em tudo, com base inteiramente nas necessidades de sua organização. Dito isto, se você optar por andar pelo caminho TDD, como o profeta Clapton predisse: “É da maneira que você o usa.”

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 deficiências de um projeto, mas é um artesão pobre que culpa suas ferramentas. Então, vamos nos concentrar 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 você optar por implementar alguma forma de desenvolvimento orientado a testes, é 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 é curto-circuito ao pular 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 que o software é desenvolvido dentro.

Não ao contrário da documentação, 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 descartado. O que invariavelmente se segue é um declínio constante da qualidade global da base de código e, no seu lugar, uma acumulação de dívida técnica.

Refatoração é a etapa do processo que se esforça para transformar código que simplesmente funciona em uma base de código que é mais limpa e mais 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 atenuá-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 esse passo, você pode perder oportunidades de introspeção e melhoria incremental, e, em última análise, sua base de código corre o risco de uma transformação gradual (ou não) em uma grande bola de lama.

Para colher os benefícios do desenvolvimento orientado a testes, é 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 “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 muito tempo é gasto planejando as especificidades de um sistema sem realmente escrever qualquer código. Um projeto de “campo verde” pode ser emocionante, com todo o potencial antecipatório associado a uma folha de papel limpa. Engenheiros e arquitetos também são vítimas da tentativa-this-itis, onde defendem o uso de uma tecnologia de sabor do mês, ignorando qualquer um dos sinais de aviso de que pode não ser um bom ajuste para este projeto em particular em favor da oportunidade de experimentar algo novo ou legal. Avançar alguns meses e o framework-du-jour não está mais atendendo às necessidades da equipe, a qualidade do código está sofrendo, 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 trabalhe para a equipe e para o negócio. Se você é prejudicada por suas ferramentas, não só elas não estão agregando valor, mas elas estão trabalhando ativamente contra você. Tome cuidado em avaliar cuidadosamente qualquer estrutura que você pretende usar, e tomar o tempo para entender como você vai usá-lo. Esta abordagem é válida para todas as decisões de design, não apenas para as relacionadas com TDD!

Atamento

Em poucas palavras, a ideia de algo como TDD é fornecer uma estrutura para coletar feedback de uma maneira mais conveniente e não simplesmente uma técnica para evitar que bugs apareçam em sua base de código. Seja qual for a abordagem que você escolher, a chave deve ser que ela permita que seu negócio e seu software se adaptem mais rapidamente às tendências em mudança e às necessidades de negócios. Ao longo do caminho, lembre-se de que o TDD e seus homólogos não são simplesmente algo que você pode pedir à sua equipe de desenvolvimento para implementar e depois esquecer, e que, para alavancar efetivamente essas técnicas, deve-se tomar cuidado para abraçar e permitir a abordagem em nível cultural antes de mergulhar em detalhes de implementação, como estruturas e ferramentas.