Desenvolvimento Orientado a Testes

O que é o Desenvolvimento Orientado a Testes

Desenvolvimento Orientado a Testes é um estilo de desenvolvimento que impulsiona o design por testes desenvolvidos em ciclos curtos de:

Escrita de um único teste.
Implementar o código suficiente para o testes passar.
Refatorar o código para deixá-lo limpo.

Em uma linguagem como o Java, esse ciclo é tão curto quanto cinco minutos. Em linguagens mais antigas, com uma compilação mais lenta e um suporte de refatoração menos automatizado, esse ciclo é maior, talvez vinte minutos.

O desenvolvimento orientado a testes é diferente no desenvolvimento de grandes produtos? Não. É uma prática individual de desenvolvimento e o número de pessoas no desenvolvimento não importa.
A quantidade de código legado, tecnologia antiga e desenvolvimento integrado tem um impacto no teste de unidade e no desenvolvimento orientado a testes. Portanto, a maioria dos experimentos nesta seção estão relacionados a isto.

Um ciclo TDD Deve Ser …

Curto: O tempo de resposta para passar cada teste é curto. Pode demorar 5 minutos por ciclo.
Rítmico: Você sentirá o ritmo distintamente - “vermelho, verde, refatora... vermelho, verde, refatora...”
Incremental: Você saberá que ao escrever e passar mais testes, funcionalidades estão sendo acumuladas de forma incremental.
Focado em Design: Com um bom conhecimento dos princípios de design de software, você descobrirá que o TDD não é uma técnica de teste, mas um método de design de software.
Disciplinado: TDD é uma maneira diferente de desenvolver software. Romper o velho hábito de "codificar e corrigir" e adotar um novo hábito exigirá disciplina e persistência.

Por que TDD?

Treinando TDD

Use Treinanadores TDD

Quando um cliente nosso revisou um rascunho do livro complementar, ele mencionou que devemos enfatizar mais treinamento. “Um de nossos erros é que não fornecemos treinamento suficiente”, disse ele. Embora estivéssemos de acordo com ele, assinalamos que, uma vez que somos consultores e fornecemos tal treinamento, esse conselho não teria muita credibilidade. Podemos também adicionar um experimento “Experimente … Contrate-nos”. Assim, minimizamos o conselho relacionado à contratação de treinadores.

Mas relacionado ao desenvolvimento orientado a testes, não podemos deixar de enfatizar fortemente: contrate treinadores! Adotar TDD significa desaprender a programação tradicional e reaprender como desenhar e codificar. Nós raramente conhecemos pessoas que conseguiram adotar isso pelo auto estudo. A maioria dos desenvolvedores precisa de um treinador para programar em par com eles por dias ou semanas. O treinador constantemente os faz lembrar primeiro de fazer os testes e realmente limpar o código, incluindo o código de teste. Ele os ajuda a aplicar o TDD e a refatorar seu código real.

O desenvolvimento orientado a testes pode ser a prática ágil mais difícil de adotar, mas também é uma das maiores oportunidades para melhorar a qualidade do design e do código. Contrate treinadores!

Treinadores internos and externos

Os treinadores externos são necessários para adotar TDD porque a competência ainda não existe dentro da empresa. Mas, ao longo do tempo, os treinadores internos crescentes reduzem a dependência de externalidades e o custo do treinamento.

Dito isto, vimos várias tentativas falhas de desenvolvimento de treinadores internos. Algumas razões:

Nenhuma estrutura estava em vigor para decidir quando e com qual equipe trabalhar.
Não foi reservado tempo para treinamento. Em vez disso, os treinadores internos foram convidados a fazer o desenvolvimento normal.
Os desenvolvedores estavam menos ansiosos para aprender com treinadores internos … você nunca é um profeta em sua própria terra.
As habilidades de treinamento não foram apreciadas e desenvolvidas. O resultado é que treinadores internos qualificados muitas vezes saem para serem treinadores externos.

Escolha o treinamento interno e externo. Dependendo só de qualquer um deles é arriscado, mas combiná-los pode levar a bons resultados.

Desenvolvimento Orientado a Testes para uma melhor arquitetura

O TDD pode ajudar a melhorar a arquitetura de um sistema. Como?

Quando estamos treinando, uma solicitação frequente é ajuda para lidar com a “arquitetura inflexível” de nosso cliente. Isso geralmente se resume a problemas de alto acoplamento entre componentes - um problema comum no código legado escrito sem TDD porque o desenvolvedor original não tentou testar o componente isoladamente.

Por outro lado, quando um desenvolvedor cria um novo componente (como uma classe) com TDD, ou refatora um componente legado para ser testável em unidade, eles devem quebrar as dependências desse componente para que ele seja testável isoladamente. Isso requer o design (ou refatoração) para a injeção de dependência e o aumento do uso de mecanismos de flexibilidade: interfaces, polimorfismo, padrões de design, estruturas de injeção de dependência, pontos de função e muito mais.

Desta forma, o TDD incentiva o acoplamento mais baixo e as qualidades de configuração simples e flexíveis de uma boa arquitetura.