O Que É Test-Driven Development (TDD)?

large__8282043567 o Desenvolvimento Orientado a testes é um processo que se baseia na repetição de um ciclo de desenvolvimento muito curto. É baseado no conceito test-first De Extreme Programming (XP) que incentiva o design simples com alto nível de confiança.

o procedimento de fazer TDD é o seguinte:

  1. Escrever um teste
  2. Executar todos os testes
  3. Escrever o código de implementação
  4. Executar todos os testes
  5. Refatorar

Este procedimento é muitas vezes chamado de Red-Green-Refactor.

enquanto escrevemos testes, estamos no estado vermelho. Como o teste é escrito antes da implementação real, ele deve falhar. Se isso não acontecer, o teste está errado. Descreve algo que já existe ou foi escrito incorretamente. Estar em verde enquanto escreve testes é um sinal de falso positivo. Testes como esse devem ser removidos ou refatorados.

em seguida vem o estado verde. Quando a implementação do último teste for concluída, todos os testes devem passar. Caso contrário, a implementação está errada e deve ser corrigida.

a ideia não é tornar a implementação final, mas fornecer Código suficiente para a aprovação dos testes. Assim que tudo estiver verde, podemos refatorar o código existente. Isso significa que estamos tornando o código mais ideal sem introduzir novos recursos. Embora a refatoração esteja em vigor, todos os testes devem passar o tempo todo. Se um deles falhar, o refactor quebrou uma funcionalidade existente. Refatoração não deve incluir novos testes.

a velocidade é a chave

large_5836417589
eu costumo ver TDD como um jogo de pingue-pongue (ou tênis de mesa). O jogo é muito rápido. O mesmo vale para TDD. Costumo não gastar mais de um minuto em ambos os lados da tabela (teste e implementação). Escreva um teste curto e execute-o (ping), escreva a implementação e execute todos os testes (pong), escreva outro teste (ping), escreva a implementação desse teste (pong), refatore e confirme que todos os testes estão passando (pontuação), repita. Ping, pong, ping, pong, ping, pong, pontuação, servir, novamente. Não tente fazer o código perfeito. Em vez disso, tente manter a bola rolando até pensar que é hora certa de marcar (refatorar).

não se trata de testar

T no TDD é frequentemente mal compreendido. TDD é a maneira como abordamos o design. É a maneira de nos forçar a pensar sobre a implementação antes de escrever o código. É a maneira de estruturar melhor o código. Isso não significa que os testes resultantes do uso de TDD Sejam Inúteis. Longe disso. Eles são muito úteis e nos permitem desenvolver com grande velocidade sem ter medo de que algo seja quebrado. Isso é especialmente verdadeiro quando ocorre refatoração. Ser capaz de reorganizar o código enquanto tem a confiança de que nenhuma funcionalidade é quebrada é um grande impulso para a qualidade do Código.

o principal objetivo do TDD é o design de código com testes como um produto lateral Muito útil.

zombando

para que os testes sejam executados rapidamente, fornecendo feedback constante, o código precisa ser organizado de forma que métodos, funções e classes possam ser facilmente ridicularizados e arrancados. A velocidade da execução será severamente afetada, por exemplo, nossos testes precisam se comunicar com o banco de dados. Ao zombar de dependências externas, podemos aumentar drasticamente essa velocidade. A execução do conjunto de testes de unidade inteira deve ser medida em minutos, se não em segundos. Mais importante do que a velocidade, projetar o código de uma forma que possa ser facilmente ridicularizado e stubbed nos força a estruturar melhor esse código aplicando separação de preocupações. Com ou sem zombarias, o código deve ser escrito de uma forma que possamos, por exemplo, substituir facilmente um banco de dados por outro. Esse “outro” pode ser, por exemplo, zombado ou no banco de dados da memória.

um exemplo de zombaria no Scala pode ser encontrado no Scala Test-Driven Development (TDD): operações de arquivo de teste de unidade com Specs2 e Mockito artigo. Se a sua linguagem de programação de escolha não é Scala, artigo ainda pode ser muito útil, a fim de ver o padrão que pode ser aplicado a qualquer linguagem.

Watchers

ferramenta muito útil quando se trabalha na moda TDD são watchers. Eles são estruturas ou ferramentas que são executadas antes de começarmos a trabalhar e estão observando qualquer alteração no código. Quando essa alteração é detectada, todos os testes são executados. No caso de JavaScript, quase todos os sistemas de construção e corredores de tarefas permitem isso. Gulp (meu favorito) e Grunt são dois de muitos exemplos. Scala tem revólver sbt (entre outros). A maioria das outras linguagens de programação tem ferramentas semelhantes que recompilam (se necessário) e executam todos os testes (ou afetados) quando o código muda. Eu sempre acabo tendo minha tela dividida em duas janelas. Um com o código em que estou trabalhando e o outro com resultados de testes que estão sendo executados continuamente. Tudo o que tenho a fazer é prestar atenção que a saída desses observadores corresponde à fase em que estou (vermelho ou verde).

documentação

outro efeito colateral muito útil do TDD (e testes bem estruturados em geral) é a documentação. Na maioria dos casos, é muito mais fácil descobrir o que o código faz observando os testes do que a própria implementação. O benefício adicional que outros tipos de documentação não podem fornecer é que os testes nunca estão desatualizados. Se houver alguma discrepância entre os testes e o código de implementação, os testes falharão. Testes com falha significam documentação imprecisa.

testes como artigo de documentação fornece um raciocínio um pouco mais profundo por trás do uso de testes em vez de documentação tradicional.

resumo

na minha experiência, TDD é provavelmente a ferramenta mais importante que temos em nossa caixa de ferramentas de software. É preciso muito tempo e paciência para se tornar proficiente em TDD, mas uma vez que a arte é dominada, a produtividade e a qualidade aumentam drasticamente. A melhor maneira de aprender e praticar TDD é em combinação com a programação de pares. Como em um jogo de pingue-pongue que requer dois participantes, o TDD pode estar em pares onde um codificador escreve testes e o outro Escreve a implementação desses testes. As funções podem mudar após cada teste (como geralmente é feito na codificação de dojos).

experimente e não desista quando se deparar com obstáculos, pois haverá muitos.

Test Driven Development (TDD): as melhores práticas usando exemplos Java são um bom ponto de partida. Mesmo que use exemplos Java, as mesmas práticas, se não todas, podem ser aplicadas a qualquer linguagem de programação. Para um exemplo em Java (como no caso anterior, é facilmente aplicável a outras linguagens), dê uma olhada no artigo passo a passo do exemplo TDD.

outra ótima maneira de aperfeiçoar as habilidades TDD são o código katas (há muitos neste site).

Qual é a sua experiência com TDD? Existem tantas variações quanto equipes praticando e eu gostaria de ouvir sobre sua experiência.

Deixe uma resposta

O seu endereço de email não será publicado.