O que é Test Driven Development (TDD)?

Agile 101

Desenvolvimento orientado a teste/ Test Driven Development ou TDD

Você se lembra daquele dia não há muito tempo? Foi no final de uma longa e difícil semana terminando o novo release. Mas ao invés de comemorar, vocês estavam todos tentando freneticamente descobrir como consertar um bug. Vocês tinham o pessoal do suporte nos seus pescoços porque os clientes os perseguiam. Naquela tarde, você decidiu: “Nunca mais”. Ou pelo menos não com a regularidade que esmaga a alma. Desde então, você encontrou a resposta: Test Driven Development (TDD). E neste artigo você aprenderá o que é, o que você ganha e como fazer.

O que é Desenvolvimento orientado a teste/ Test Driven Development (TDD)?

Desenvolvimento orientado a teste é um processo no qual você escreve o teste antes de escrever o código. E quando todos os testes estão passando você limpa sua cozinha: você melhora o código. No Entanto, Test Driven Development Não Se Trata de Testes A premissa por trás do desenvolvimento orientado a testes, segundo Kent Beck, é que todos os códigos devem ser testados e refatorados continuamente. Isso certamente parece se tratar de testes, então, como assim? Bem, os testes que você escreve em TDD não são o ponto, mas sim os meios. A questão é que ao escrever testes primeiro e esforçar-se para mantê-los fáceis de escrever, você está fazendo três coisas importantes.

So What Are the Benefits of Test Driven Development?

Portanto, Quais São os Benefícios do Test Driven Development?

Além dos benefícios mencionados na seção anterior, o TDD também o proporciona:

O que tudo isso significa para o seu negócio, é:

O Surpreendente Motivo para usar TDD

Se todos esses benefícios não forem suficientes, há mais um motivo para usar TDD, um motivo que o surpreenderá. Kent Beck afirma: “Muito simplesmente, test driven development visa eliminar o medo no desenvolvimento de aplicações”. O medo é bom para mantê-lo vivo, mas é um assassino para o trabalho que precisa até mesmo do mínimo de cognição.

Hã, e Sobre “Desenvolvedores Não Devem Escrever os Testes para Testar seu Próprio Código?

Sim, há boas razões para não deixar os desenvolvedores escreverem os testes para testar seu próprio código. No entanto, este conselho se aplica aos testes de nível de aplicação. Para testes de nível de desenvolvimento, conseguir que outra pessoa escreva os testes é como amarrar o cavalo atrás da carroça. Os requisitos geralmente são vários níveis de abstração acima do código necessário para implementá-lo. Portanto, é preciso pensar no que se precisa fazer e como se fará. Escrever os testes primeiro é uma maneira excelente e eficiente de fazer isso. E, lembre-se, TDD não se trata de testes.

E Onde o Test Driven Development Se Encaixa em Agile?

Em 1996, a equipe do projeto C3 da Chrysler praticou a programação test-first. “Nós sempre escrevemos testes unitários antes de lançar qualquer código, geralmente antes mesmo de escrever o código”, diz o estudo de caso do projeto intitulado “Chrysler Goes to “‘Extremes’”.”. Os testes de escrita primeiro foram apenas uma das práticas utilizadas pela equipe C3. Em conjunto, essas práticas ficaram conhecidas como eXtreme Programming. Três membros dessa equipe, Kent Beck, Martin Fowler e Ron Jeffries, estavam entre as pessoas que escreveram e assinaram pela primeira vez o Manifesto Agile. O test driven development é uma prática Agile essencial. Ela suporta diretamente o valor Agile de “Software funcional acima de documentação abrangente”. E o faz protegendo o software funcional com testes e criando a documentação como um subproduto natural.

Legal, Então Se Pratica o TDD

Src: Spec-india.com

O test driven development é enganosamente simples. Fácil de explicar o que se faz, mas não tão fácil de fazer de fato. Mais sobre o porquê disso na próxima seção. Primeiro, vamos explicar o que você faz em TDD.

O Ciclo e as Fases do TDD

Test Driven Development significa passar por três fases. De novo e de novo e de novo.

Só isso? Sim, só isso mesmo.
Mas espere, há mais.

As Regras do TDD Como Explicadas pelo Tio Bob

Tio Bob (Robert C. Martin) definiu as regras do TDD no capítulo 5 “Test Driven Development” de seu livro The Clean Coder.

Por que seguir estas regras? Porque elas se destinam a facilitar sua vida.

Mas eu não estou satisfeito com a regra nº 2. Porque tratar os erros de compilação como falhas pode mascarar o fato de que um teste não tem afirmações. E isso é ruim, porque pode enganar você a pensar que um teste está passando quando o código está (em parte) não escrito ou simplesmente errado.

Dito isto, a intenção das regras é manter as coisas concentradas em cada fase e evitar que você fique em ciclos. Por experiência própria, isso ajuda muito a manter as coisas claras em sua cabeça. Por isso:

Às vezes você encontrará oportunidades para refatorar o código de teste. Por exemplo, quando você tem um monte de testes [Fatos] separados em xUnit que só diferem nos argumentos que passam para o método em teste. Você pode substituí-los por um único teste [Teoria]. Meu conselho: não refatorar, mas acrescentar a teoria e quando isso estiver de acordo com os fatos, você pode remover os fatos.

Exemplos de Uso de TDD

Vamos tornar tudo isso um pouco mais concreto com um exemplo. Então, digamos que você seja encarregado de criar um método que converta os números decimais em números romanos.

Step 1: Red phase, write a test. Decimal 1 should return “I”.

A execução do teste não é possível neste momento, porque a classe Romanizer ainda não existe e isso significa erros de compilação.

Passo 2: Fase verde, fazer o teste passar

Adicione a classe Romanizer e dê-lhe um método FromDecimal que pega uma integer e retorna uma string.

Eu gosto de ter certeza de que o teste ainda falha quando o código é compilado. Dessa forma, sei que estou começando com um teste falhado como resultado de afirmações nos testes.

Portanto, escrevo uma implementação que tenho certeza de que falhará.

Passo 1: Fase vermelha, escreva um teste.

Add the Romanizer class and give it a FromDecimal method that takes an integer and returns a string. I like to make sure that the test still fails when the code compiles. That way I know I’m starting with a failing test as a result of assertions in the tests. So I write an implementation that I’m sure will fail.

Execute os testes e sim, o teste falha. Boa!

Agora crie a implementação mais simples que fará o teste passar.

Bobo? Não. O código está correto e faz o teste passar.

A criação de um algoritmo que possa funcionar é prematura nesta fase. Você pode acertá-lo, mas é mais provável que não o faça. E isso pode te colocar em problemas (veja mais abaixo). Passo 3: Fase azul, refatorar Ainda não há muito para refatorar, portanto, para o próximo teste. Passo 4: Fase vermelha, escreva um teste O decimal 2 deve retornar “II”.

Passo 3: Fase azul, refatorar

Ainda não há muito para refatorar, portanto, para o próximo teste.

Passo 4: Fase vermelha, escreva um teste

O decimal 2 deve retornar “II”.

Faça todos os testes para ver este falhar. Isto é muito importante! Ele permite que você tenha certeza de que é sua implementação que o fará passar e não a falta de afirmações em seu teste.

Ok. Para a fase verde.

Passo 5: Fase verde, faça o teste passar

Mais uma vez, escreva o código mais simples que fará o teste passar.

Hmm. Não gosto que o if-else-if fique muito grande, mas vamos primeiro executar os testes.

And yes, it does make all the tests pass.

Passo 6: Fase azul, refatorar

Esta estrutura if-else-if não é muito elegante, mas dois casos ainda não merecem ser refatorados, e assim por diante para o próximo teste.

Passo 7: Fase vermelha, escreva um teste

O decimal 3 deve retornar “III”.

E executar todos os testes para ver este falhar. (E nenhum outro!)

Passo 8: Fase verde, fazer o teste passar

Mais uma vez, o código mais simples para fazer o teste passar.

Isto está começando a ficar bem feio, mas primeiro execute os testes.

Sim, tudo verde, então podemos finalmente fazer algo a respeito dessa estrutura se-else-if, porque 3 casos merecem uma refatoração, como agora se aplica a Regra de 3.

Passo 9: Fase azul, refatorar

O padrão é claro. Você precisa de tantos “I” quanto o número que foi passado.

Execute todos os testes para garantir que cada um deles ainda passe.

Algumas reflexões extras

Claro que, sabendo como funcionam os numerais romanos, o padrão não se manterá. Mas quebrar o cérebro com um algoritmo de antecedência não é o caminho a seguir. Você provavelmente acabará ajustando-o para cada teste que você adicionar. E ficar mal-humorado quando cada ajuste provoca o fracasso de diferentes testes. Quando você escreve o código e o refatora para algo mais simples, você aumenta o algoritmo à medida que você avança. Uma maneira muito melhor e mais fácil de fazer isso.

Regras de Refatoração

Quando você refatora, não o faz de forma aleatória. Você segue um processo estruturado para limpar o código. Você identifica code smells e aplica uma refatoração específica para removê-los. Martin Fowler escreveu o livro sobre como fazer isso: Refactoring: Improving the Design of Existing Code. O objetivo da refatoração é melhorar a extensibilidade de seu código através de

O que é realmente importante é que a refatoração é o que deixa o código limpo, descomplicado, fácil de entender, de modificar e de testar. E você já leu o que isso lhe proporciona.

Por Que é Tão Difícil Exercer o TDD?

Praticar o TDD não é um mar de rosas. Pelo menos não a princípio. Aqui estão os motivos.

Como Você Pode Falhar no TDD — Quais São os Erros Comuns?

Você pode falhar na prática do TDD de muitas maneiras diferentes:

Escrever testes para código trivial, tais como accessors e vistas sem lógica.

Recursos Para Aprender e Melhorar

What Is the Difference Between TDD and BDD?

Qual é a Diferença entre TDD e BDD?

Behavior Driven Development e Test Driven Development são ao mesmo tempo similares e diferentes.

A vida é boa quando suas equipes Agile estão sincronizadas!

Contate-Nos hoje para uma demonstração personalizada do SwiftEnterprise! Ou inscreva-se para atualizações abaixo.