O que é desenvolvimento orientado por testes (TDD)?

Os desenvolvedores escrevem apenas o código necessário para passar em cada teste; em seguida, tanto o teste quanto o código são refinados antes de avançar para um novo teste e depois para uma nova funcionalidade.

O desenvolvimento orientado por testes essencialmente força os desenvolvedores a reduzir o ritmo, validar e refinar o código em ciclos de feedback mais curtos Embora não seja obrigatório, as equipes de DevOps incentivam programadores, de iniciantes a profissionais experientes, a usar o TDD em uma ampla variedade de linguagens de programação. Por exemplo, Java, Python e outras, interfaces de programação de aplicativos (APIs) e aplicações de programas.

Programar nesse estilo fortalece a relação entre programação, testes (na forma de testes automatizados em nível de unidade) e design de código. Embora o desenvolvimento orientado por testes possa aumentar o tempo inicial de desenvolvimento, já foi demonstrado que ele melhora a funcionalidade e a flexibilidade do código e economiza tempo no geral.

Ao identificar e lidar imediatamente com qualquer erro, os desenvolvedores que usam TDD podem evitar que pequenos problemas se tornem maiores. O desenvolvimento orientado por testes obriga os desenvolvedores a validar e refinar o código enquanto avançam, agilizando assim as verificações e correções finais de qualidade.

Frameworks de teste alternativos incluem escrever o código de produção antes de todos os testes automatizados ou escrever toda o pacote de testes antes do código de produção. Esses métodos, embora não necessariamente ineficazes, demonstraram aumentar o tempo necessário de depuração, especialmente em projetos maiores e mais complexos.

O desenvolvimento orientado por testes é comumente usado para a criação de novos códigos de produção, mas também é frequentemente aplicado para melhorar a depuração de código legado desenvolvido com técnicas mais antigas ou diferentes.

O desenvolvimento orientado por testes inverte o processo tradicional de desenvolvimento ao colocar os testes antes do desenvolvimento Como uma abordagem iterativa, ele melhora a qualidade e a legibilidade do código ao promover fluxos de trabalho testáveis que resultam em código de alta qualidade no nível de unidade. Quando desenvolvedores implementam testes de unidade, eles se concentram em uma pequena porção da lógica, como um algoritmo individual. Escrever código especificamente para que os testes passem não apenas resulta em código mais limpo e durável, mas também ajuda a melhorar a documentação.

Existem dois principais níveis de desenvolvimento orientado por testes.

No desenvolvimento orientado por testes de aceitação — às vezes chamado de desenvolvimento orientado por comportamento (BDD) — os programadores escrevem um único teste de aceitação e, em seguida, apenas o código necessário para que ele seja aprovado. Testes de aceitação às vezes são chamados de testes de cliente ou testes de aceitação do cliente.

Geralmente, podem ser entendidos como casos de teste necessários para a funcionalidade mínima, conforme descrito pelos stakeholders do produto. O ATDD busca identificar requisitos detalhados e executáveis. Os testes de aceitação podem ser realizados com diversas ferramentas de teste, como Fitnesse ou RSpec.

Às vezes chamado simplesmente de TDD, o TDD do desenvolvedor exige que os programadores escrevam testes individuais para avaliar sua própria solução a um teste de ATDD. O TDD do desenvolvedor usa ferramentas de automação de testes, como JUnit ou VBUnit.

Ao empregar uma estratégia de desenvolvimento orientado a testes, os programadores primeiro escrevem testes para verificar cada elemento ou função individual de um software antes de escrever código suficiente para passar nesse teste individual. Uma vez concluído, o software é testado novamente e, se aprovado, o código é refinado (um processo conhecido como refatoração) para incluir apenas os elementos essenciais. Os desenvolvedores então repetem esse processo para cada função subsequente do software.

O processo de desenvolvimento orientado por testes é dividido em cinco etapas individuais:

1. Antes de escrever o código para uma determinada função de software, os desenvolvedores primeiro escrevem um teste de unidade individual para essa função.
2. Em seguida, os desenvolvedores executam o teste, que deve falhar porque a função de código ainda não foi escrita. Essa etapa é importante para confirmar que o teste em si é funcional e não retorna falsos positivos. Se o código passar, isso indica que o teste precisa ser reescrito.
3. Quando o programa falha no teste, os desenvolvedores escrevem apenas o suficiente de código adicional para que o teste seja aprovado.
4. Quando o código consegue passar no teste, tanto o teste quanto o código são refatorados para simplificação e para eliminar qualquer código desnecessário.
5. Quando o software suficientemente refatorado consegue passar no teste também refatorado, os desenvolvedores seguem para a próxima função desejada de software. Os testadores então escrevem e executam testes para cada novo recurso.

De forma simples, o processo de desenvolvimento orientado por testes segue um ciclo repetitivo, conhecido como ciclo vermelho-verde-refatorar. As etapas do ciclo são:

• Vermelho: escrever um teste com falha para o comportamento de software pretendido

• Verde: escrever apenas o suficiente para passar no teste.

• Refatorar: refinar o código para atender a padrões de simplicidade o máximo possível, ainda garantindo a aprovação no teste.

Embora as origens específicas do desenvolvimento orientado por testes sejam desconhecidas, o conceito de escrever os testes primeiro e o código de produção em segundo lugar não era uma prática comum até meados da década de 1990. Antes disso, os frameworks de testes separavam os desenvolvedores da verificação de seus próprios códigos. No entanto, à medida que a engenharia de software evoluiu, as equipes de DevOps passaram a demandar metodologias mais rápidas e flexíveis para atender às necessidades dos stakeholders, especialmente em contextos de requisitos em constante mudança.

O desenvolvimento orientado por testes evoluiu a partir de vários frameworks de testes inovadores e, com o tempo, foi adotado como um componente modular em outros frameworks também. Mais notavelmente, ele está incluído no conceito de Extreme Programming (XP), um framework ágil de desenvolvimento de software criado para melhorar tanto a qualidade do software quanto a qualidade de vida dos desenvolvedores.

O engenheiro de software Kent Beck, uma figura importante na comunidade ágil e criador do Extreme Programming, é creditado por ter “redescoberto” o desenvolvimento orientado por testes. Nas palavras do próprio Beck:

“A descrição original do TDD estava em um livro antigo sobre programação. Dizia que você deve pegar a fita de input, digitar manualmente a fita de saída que espera e, em seguida, programar até que a fita de saída real corresponda à saída esperada. Depois que escrevi o primeiro framework xUnit em Smalltalk, lembrei-me de ter lido isso e decidi experimentar. Essa foi a origem do TDD para mim. Ao descrever o TDD para programadores mais experientes, frequentemente ouço: ‘Claro. De que outra forma você programaria?’. Portanto, considero meu papel como o de 'redescobrir' o TDD.”

Datas notáveis na evolução do desenvolvimento orientado por testes incluem:

• 1976: Glenford Myers publica Software Reliability, no qual argumenta que “um desenvolvedor nunca deve testar o próprio código”. Embora Myers possa não ter sido o criador desse conceito, seu trabalho deu credibilidade a uma noção comum que perduraria por muitos anos.

• 1990: no início da década, a técnica de “caixa-preta” dominava o teste de software. Nesse tipo de framework de teste, os testadores tratam o software como se fosse uma “caixa-preta”, impenetrável e desconhecida. O teste de caixa-preta utiliza testadores que, de forma crítica, não têm conhecimento do funcionamento interno do software.

• 1994: Kent Beck desenvolve o SUnit, um framework de testes em Smalltalk, estabelecendo as bases para uma abordagem de teste antecipado com foco na otimização da base de código.

• 1999–2002: à medida que o movimento de desenvolvimento ágil ganha força, Kent Beck desenvolve o conceito de Extreme Programming, codificando o TDD e introduzindo o conceito crítico de objetos simulados (mock objects). O TDD utiliza objetos simulados para reproduzir o comportamento de dependências reais (por exemplo, bancos de dados, serviços externos etc.) durante os testes. Esse método ajuda os desenvolvedores a focar o código de teste em objetos simulados sustentáveis, que podem ser verificados para garantir desempenho preciso. Um teste que falha utilizando um objeto simulado pode eliminar uma dependência possivelmente mal configurada como causa da falha.

• 2003: Kent Beck publica Test Driven Development: By Example, popularizando a prática entre a comunidade de desenvolvimento mais ampla e legitimando ainda mais os testes conduzidos por desenvolvedores.

Como componente da Extreme Programming, o desenvolvimento orientado por testes mostrou-se benéfico não apenas para criar um código melhor, mas também programadores melhores. O TDD pode permitir que os programadores compreendam melhor seus projetos e ajudem a orientar o design do programa. Ao colocar o caso de teste antes da implementação de cada funcionalidade, os desenvolvedores precisam visualizar como uma função será utilizada por um cliente ou usuário. Essa abordagem posiciona a interface do produto antes da implementação e ajuda os desenvolvedores a criarem aplicações mais centradas no usuário.

Alguns benefícios adicionais do desenvolvimento orientado por testes incluem:

• Cobertura abrangente de testes: o TDD às vezes é considerado uma ferramenta de especificação ou documentação porque a prática garante que todo o código esteja coberto por pelo menos um teste.

• Documentação aprimorada: pelo mesmo motivo que o TDD garante cobertura abrangente, ele também fornece documentação e especificação robustas. Esse sistema ajuda desenvolvedores, gerentes de projeto e outros stakeholders a validarem funcionalidades e requisitos do código, além de estabelecer ordem ao longo do ciclo de vida do projeto.

• Maior confiança: desenvolvedores e equipes de DevOps que utilizam TDD ganham mais confiança não apenas no próprio código, mas também nos testes realizados.

• Facilita a integração contínua: o TDD é adequado para práticas de integração contínua, em que o código em produção é continuamente atualizado com novas funcionalidades e correções.

• Menos depuração: o TDD antecipa a fase de testes no processo de desenvolvimento, reduzindo a necessidade de extensas depurações no final.

• Maior clareza de requisitos: o TDD ajuda os desenvolvedores a estabelecerem um entendimento claro de cada requisito específico do programa antes de iniciar o trabalho.

• Maior produtividade: o TDD costuma estar associado a um aumento na produtividade dos desenvolvedores, já que o processo ajuda a dividir grandes projetos em etapas menores e mais alcançáveis.

• Reforço do design simples: a terceira etapa crítica do ciclo verde-vermelho-refatorar do TDD exige que os desenvolvedores refatorem e simplifiquem o código. Essa prática melhora a simplicidade geral e a qualidade do design.

• Fortalecimento de modelos mentais: ao examinar e integrar cada função ou requisito exclusivo, o TDD ajuda os programadores a desenvolverem um modelo mental sólido do código em questão. Esse modelo mental ajuda os desenvolvedores com a visualização das funções e os requisitos gerais do código enquanto trabalham nele.

• Maior estabilidade do sistema: o uso do desenvolvimento orientado por testes demonstrou melhorar a estabilidade geral da aplicação, criando código robusto, bem testado e alinhado a altos padrões de simplicidade no design.

Embora haja muitos benefícios valiosos no uso do TDD, ele não está livre de desafios. Embora a gravidade desses desafios possa depender do projeto ou ser atenuada por diversas outras técnicas, algumas das desvantagens do TDD incluem:

• Maior volume de código: o TDD exige que os programadores escrevam não apenas o código para cada funcionalidade necessária, mas também os testes para cada funcionalidade. A adição do código de teste junto ao código do produto resulta em uma base de código geral maior.

• Confiança falsa: como cada funcionalidade é escrita para passar em um teste, programadores e gerentes de projeto podem desenvolver uma falsa sensação de segurança em relação à funcionalidade geral do código. Embora cada funcionalidade integrada seja testada, o TDD não substitui a necessidade de controle de qualidade final e de teste de API.

• Aumento de sobrecarga: o TDD exige que os programadores também mantenham um grande pacote de testes, além de seu código de produção. A manutenção de bases de código de teste requer uma certa quantidade de recursos e pode aumentar os custos de sobrecarga.

• Redução de eficiência: embora o TDD tenha demonstrado melhorar a produtividade, ele pode atrasar o desenvolvimento do projeto, pois adiciona mais etapas à criação e implementação de cada nova funcionalidade.

• Maior tempo de configuração: o TDD exige que os desenvolvedores configurem e mantenham ambientes de teste adequados para seu código.

• Negligência no design geral: embora o TDD incentive a simplicidade do código e a melhoria do design, focar demais em componentes individuais pode levar a um código geral menos harmonioso. Programadores que utilizam TDD precisam saber como suas atualizações individuais de funcionalidades serão integradas quando compiladas no aplicativo de software como um todo.