O que é Test Driven Development, abordagens e vantagens

Test Driven Development (TDD) é uma abordagem de desenvolvimento de software em que os casos de teste são desenvolvidos para especificar e validar o que o código fará.

Virtualmente, casos de teste para cada recurso são criados e testados antes do lançamento do software e, se o teste falhar, um novo código é escrito (ou reescrito ou corrigido) para passar no teste e tornar o código simples e livre de erros.

Test Driven Development (TDD) começa com a concepção e desenvolvimento de testes para cada pequeno recurso em um aplicativo. A estrutura TDD instrui os desenvolvedores a escrever um novo código somente se um teste automatizado falhar. Essa abordagem evita a duplicação de código. O módulo TDD completo é um desenvolvimento orientado a testes.

Test Driven Development (TDD) originou-se como parte de um paradigma maior de design de software conhecido como Extreme Programming (XP), que faz parte da metodologia de desenvolvimento de software Agile.

O conceito simples de TDD é escrever e corrigir testes com falha antes de escrever um novo código (antes do desenvolvimento). Isso ajuda a evitar a duplicação de código, pois escrevemos uma pequena quantidade de código por vez para passar nos testes. (Testes nada mais são do que condições de requisitos que temos que testar para satisfazê-los).

O desenvolvimento orientado a testes é um processo de desenvolvimento e execução de testes automatizados antes do desenvolvimento real do aplicativo. Conseqüentemente, o TDD também é às vezes chamado de Test First Development.

Fases da abordagem TDD

Antes de qualquer novo código ser escrito, o programador deve primeiro criar um teste de unidade com falha. Então, o programador – ou casal, ou mob – cria apenas o código suficiente para satisfazer esse requisito. Uma vez aprovado o teste, o programador pode refatorar o projeto, fazendo melhorias sem alterar o comportamento.

Embora o TDD se concentre nas interações do programador em nível de unidade, existem outros métodos populares, como o desenvolvimento orientado a testes de aceitação (ATDD) ou o desenvolvimento orientado a comportamento (BDD), que se concentram em testes que podem ser compreendidos pelos clientes.

Esses métodos envolvem a criação de exemplos do mundo real como testes colaborativos entre a equipe de engenharia e o cliente antes da codificação e, em seguida, a execução dos testes após a codificação para demonstrar que o código foi implementado. Ter os testes conhecidos com antecedência melhora a qualidade da primeira vez. ATDD e BDD exigem que desenvolvedores, testadores e o lado comercial trabalhem juntos para imaginar e discutir o software e suas implicações antes que o código seja criado.

Vantagens do TDD

O desenvolvimento orientado a testes pode produzir aplicativos de alta qualidade em menos tempo do que é possível com métodos mais antigos. A implementação bem-sucedida do TDD exige que os desenvolvedores e testadores antecipem com precisão como o aplicativo e sua funcionalidade serão usados ​​no mundo real.

TDD constrói um conjunto de testes de regressão como um efeito colateral que pode minimizar o teste manual humano, encontrando problemas mais cedo, levando a soluções mais rápidas. A natureza metódica do TDD garante cobertura e qualidade iniciais muito mais altas do que os clássicos ciclos de código em fases > teste > correção > reteste. Como o teste é realizado no início do ciclo de design, o tempo e o dinheiro gastos na depuração posterior são minimizados.

Benefícios esperados:

• reduções significativas nas taxas de defeitos, ao custo de um aumento moderado no esforço inicial de desenvolvimento
• custos indiretos são mais do que compensados ​​por uma redução no esforço nas fases finais dos projetos
• O TDD leva a melhores qualidades de design no código e, de forma mais geral, a um maior grau de qualidade "interna" ou técnica, por exemplo, melhorando as métricas de coesão e acoplamento

Desvantagens do TDD

O TDD requer habilidade considerável para ser bem-sucedido, especialmente no nível da unidade. Muitos sistemas legados simplesmente não são construídos com o teste de unidade em mente, impossibilitando o isolamento de componentes para teste.

Além disso, muitos programadores carecem de habilidades para isolar e criar código limpo. Todos os membros da equipe devem criar e manter testes de unidade ou eles se tornarão rapidamente obsoletos. E uma organização olhando para o TDD terá que investir tempo, desacelerar um pouco agora para ir mais rápido depois.

Finalmente, como acontece com qualquer método, os resultados finais do TDD são tão bons quanto os testes que foram usados, com que precisão foram executados e até que ponto eles imitam as condições encontradas pelos usuários do produto final.

Erros comuns:

• esquecendo-se de executar testes com frequência
• escrever muitos testes de uma só vez
• escrever testes que são muito grandes ou grosseiros
• escrever testes excessivamente triviais, como omitir asserções
• escrever testes para código trivial
• adoção parcial: apenas alguns desenvolvedores em um grupo de trabalho usam TDD
• manutenção deficiente do conjunto de testes, geralmente levando a um conjunto de testes com um tempo de execução proibitivamente longo
• conjunto de testes abandonado (ou seja, raramente ou nunca é executado) – às vezes devido à má manutenção, às vezes devido à rotatividade da equipe

Filosofia TDD

O TDD permite que o programador dê pequenos passos ao escrever software. O teste é escrito antes de testar a funcionalidade e garante que o aplicativo seja adequado para testabilidade. O teste em uma pequena quantidade de código é feito para detectar erros que ocorrem no código testado. Em seguida, a funcionalidade é implementada. Isso é chamado de "refator verde vermelho", onde vermelho significa falha e verde mostra uma aprovação. Essas etapas são então repetidas. O primeiro objetivo de um programador é se concentrar na tarefa em questão e superá-la.

Os diferentes estágios envolvidos em um ciclo de desenvolvimento orientado a testes são:

• Adicione um teste: Cada novo recurso no TDD começa com um teste que deve falhar, pois é colocado em prática antes de qualquer recurso ser implementado. O pré-requisito para escrever um teste antes de implementar o recurso é um entendimento claro do requisito pelo desenvolvedor. Isso é alcançado por meio de histórias de usuários e casos de uso. Portanto, um desenvolvedor entende o requisito antes de escrever o código do programa.
• Execute todos os testes e verifique se o novo código falha: isso garante que o equipamento de teste funcione corretamente e que o novo teste não falhe sem nenhum novo código. Essa etapa também verifica o teste e elimina a possibilidade de que o novo teste sempre passe.
• Escrever código: A próxima etapa a seguir é escrever o código que limpa o teste. O novo código não é perfeito, mas é modificado posteriormente de acordo com os requisitos. Ele é projetado simplesmente para testes e não inclui outros recursos.
• Executar testes automatizados: Se cada caso de teste produzido passar no teste com facilidade, significa que o código atende a todas as especificações exigidas. Então a fase final do ciclo pode ser iniciada.
• Código de refatoração: é semelhante à remoção de duplicação. Uma refatoração não quebra nenhuma funcionalidade existente e ajuda a remover a duplicação entre a produção e o código de teste. O código agora está limpo conforme solicitado.
• Repetir: O ciclo se repete como nos casos anteriores com um novo teste. O requisito essencial é que o tamanho da etapa seja pequeno, com cerca de 1 a 10 alterações entre cada execução de teste. Se o novo código falhar em um novo teste, o programador deve fazer mais depurações. A integração contínua fornece pontos de verificação reversíveis.

Ercole Palmeri