BDD - Desenvolvimento Orientado a Testes

Quando você olha para qualquer referência sobre Behavior Driven Development, você encontrará o uso de frases como “BDD é derivado de TDD”, “BDD e TDD”. Para saber como o BDD surgiu, por que se diz que ele é derivado do TDD e o que é BDD e TDD, é necessário entender o que é TDD.

Por que testar?

Para começar, vamos entrar nos fundamentos do teste. O objetivo do teste é garantir que o sistema construído esteja funcionando conforme o esperado. Considere o seguinte exemplo.

Conseqüentemente, por experiência, aprendemos que descobrir um defeito como e quando ele é introduzido e consertá-lo imediatamente seria econômico. Portanto, há uma necessidade de escrever casos de teste em cada estágio de desenvolvimento e teste. Isso é o que nossas práticas de teste tradicionais nos ensinaram, o que geralmente é denominado como Teste antecipado.

Essa abordagem de teste é denominada abordagem Teste-Último, pois o teste é feito após a conclusão de um estágio.

Desafios com a abordagem Test-Last

A abordagem Test-Last foi seguida por algum tempo nos projetos de desenvolvimento de software. No entanto, na realidade, com esta abordagem, como o teste tem que esperar até que o estágio específico seja concluído, muitas vezes é esquecido por causa de -

  • Os atrasos na conclusão da etapa.

  • Horários apertados.

  • Concentre-se na entrega no prazo, evitando testes.

Além disso, na abordagem Teste-Último, o teste de unidade, que deveria ser feito pelos desenvolvedores, é frequentemente ignorado. Os vários motivos encontrados baseiam-se na mentalidade dos desenvolvedores -

  • Eles são desenvolvedores e não testadores.

  • O teste é responsabilidade dos testadores.

  • Eles são eficientes na codificação e seu código não teria defeitos.

Isso resulta em -

  • Comprometimento com a qualidade do produto entregue.

  • Ter a responsabilidade pela qualidade apenas nos testadores.

  • Custos elevados na correção de defeitos, pós-entrega.

  • Incapacidade de obter a satisfação do cliente, o que também significaria a perda de novos negócios, afetando assim a credibilidade.

Esses fatores exigiam uma mudança de paradigma para se concentrar nos testes. O resultado foi a abordagem Teste-Primeiro.

Abordagem Teste-Primeiro

A abordagem Test-First substitui a forma de desenvolvimento de dentro para fora (escrever código e depois testar) para fora para dentro (escrever teste e depois codificar).

Essa abordagem é incorporada às seguintes metodologias de desenvolvimento de software (que também são Agile) -

  • eXtreme Programming (XP)

  • THusa Drachado Development (TDD).

Nessas metodologias, o desenvolvedor projeta e grava os testes de unidade para um módulo de código antes de escrever uma única linha do módulo de código. O desenvolvedor então cria o módulo de código com o objetivo de passar no teste de Unidade. Assim, essas metodologias usam testes de unidade para conduzir o desenvolvimento.

O ponto fundamental para notar que o objetivo é o desenvolvimento baseado em testes.

Ciclo Red-Green-Refactor

O Desenvolvimento Orientado a Testes é usado para desenvolver o código guiado por testes de unidade.

Step 1 - Considere um módulo de código que deve ser escrito.

Step 2 - Escreva um teste

Step 3 - Faça o teste.

O teste falha, pois o código ainda não foi escrito. Conseqüentemente, a Etapa 2 é geralmente referida como escrever um teste para falhar.

Step 4 - Escreva o código mínimo possível para passar no teste.

Step 5- Execute todos os testes para garantir que todos eles sejam aprovados. Os testes de unidade são automatizados para facilitar esta etapa.

Step 6 - Refatorar.

Step 7 - Repita da Etapa 1 à Etapa 6 para o próximo módulo de código.

Cada ciclo deve ser muito curto e uma hora típica deve conter muitos ciclos.

Isso também é conhecido popularmente como o Red-Green-Refactor ciclo, onde -

  • Red - Escrever um teste que falha.

  • Green - Escrever código para passar no teste.

  • Refactor - Remova a duplicação e melhore o código para os padrões aceitáveis.

Etapas do processo TDD

As etapas de um processo TDD são ilustradas abaixo.

Vantagens do TDD

Os benefícios ou vantagens do Desenvolvimento Orientado a Testes são -

  • O desenvolvedor precisa entender primeiro qual deve ser o resultado desejado e como testá-lo antes de criar o código.

  • O código de um componente é concluído apenas quando o teste é aprovado e o código é refatorado. Isso garante o teste e a refatoração antes que o desenvolvedor prossiga para o próximo teste.

  • Como o conjunto de testes de unidade é executado após cada refatoração, o feedback de que cada componente ainda está funcionando é constante.

  • Os testes de unidade atuam como documentação viva que está sempre à altura dos dados.

  • Se um defeito for encontrado, o desenvolvedor cria um teste para revelar esse defeito e, em seguida, modifica o código para que o teste passe e o defeito seja corrigido. Isso reduz o tempo de depuração. Todos os outros testes também são executados e quando passam, garante que a funcionalidade existente não seja quebrada

  • O desenvolvedor pode tomar decisões de design e refatorar a qualquer momento e a execução dos testes garante que o sistema ainda está funcionando. Isso torna o software sustentável.

  • O desenvolvedor tem a confiança de fazer qualquer alteração, pois se a alteração afetar alguma funcionalidade existente, o mesmo é revelado ao executar os testes e os defeitos podem ser corrigidos imediatamente.

  • Em cada execução de teste sucessiva, todas as correções de defeitos anteriores também são verificadas e a repetição do mesmo defeito é reduzida.

  • Como a maioria dos testes é feita durante o próprio desenvolvimento, o teste antes da entrega é reduzido.

Desvantagens do TDD

O ponto de partida são as Estórias de Usuário, que descrevem o comportamento do sistema. Portanto, os desenvolvedores muitas vezes enfrentam as seguintes questões -

  • Quando testar?

  • O que testar?

  • Como saber se uma especificação é atendida?

  • O código agrega valor ao negócio?

Equívocos sobre TDD

Os equívocos a seguir existem na indústria e precisam de esclarecimentos.

Equívoco Esclarecimento
TDD trata de testes e automação de testes. TDD é uma metodologia de desenvolvimento que usa a abordagem Test-First.
O TDD não envolve nenhum projeto. O TDD inclui análise crítica e design com base nos requisitos. O design surge durante o desenvolvimento.
TDD está apenas no nível da unidade. O TDD pode ser usado nos níveis de integração e sistema.
O TDD não pode ser usado por projetos de teste tradicionais. O TDD se tornou popular com a Extreme Programming e está sendo usado em outras metodologias Agile. No entanto, ele também pode ser usado em projetos de teste tradicionais.
TDD é uma ferramenta.

TDD é uma metodologia de desenvolvimento e, após cada novo teste de unidade passar, ele é adicionado ao Automation Test Suite, pois todos os testes precisam ser executados sempre que um novo código é adicionado ou o código existente é modificado e também após cada refatoração.

Assim, as ferramentas de automação de teste que suportam o TDD facilitam esse processo.
TDD significa entregar testes de aceitação aos desenvolvedores. TDD não significa entregar testes de aceitação aos desenvolvedores.

Aceitação TDD

O Desenvolvimento Orientado ao Teste de Aceitação (ATDD) define os Critérios de Aceitação e os Testes de Aceitação durante a criação das Estórias de Usuário, no início do desenvolvimento. ATDD se concentra na comunicação e entendimento comum entre os clientes, desenvolvedores e testadores.

As principais práticas em ATDD são as seguintes -

  • Discuta cenários do mundo real para construir uma compreensão compartilhada do domínio.

  • Use esses cenários para chegar aos critérios de aceitação.

  • Automatize os testes de aceitação.

  • Concentre o desenvolvimento nesses testes.

  • Use os testes como uma especificação ao vivo para facilitar a mudança.

Os benefícios de usar ATDD são os seguintes -

  • Os requisitos são inequívocos e sem lacunas funcionais.

  • Outros entendem os casos especiais que os desenvolvedores prevêem.

  • Os testes de Aceitação orientam o desenvolvimento.

TDD Vs BDD

De acordo com Dan North, os programadores normalmente enfrentam os seguintes problemas ao executar o Desenvolvimento Orientado a Testes -

  • Onde começar

  • O que testar e o que não testar

  • Quanto testar de uma só vez

  • Como chamar seus testes

  • Como entender por que um teste falha

A solução para todos esses problemas é o Desenvolvimento Orientado ao Comportamento. Ele evoluiu a partir das práticas ágeis estabelecidas e é projetado para torná-las mais acessíveis e eficazes para as equipes, iniciantes na entrega ágil de software. Com o tempo, o BDD cresceu para abranger o quadro mais amplo de análise ágil e teste de aceitação automatizado.

O principal difference between TDD and BDD é isso -

  • TDD descreve como o software funciona.

  • Por outro lado, BDD -

    • Descreve como o usuário final usa o software.

    • Promove colaboração e comunicação.

    • Enfatiza exemplos de comportamento do Sistema.

    • Visa as especificações executáveis ​​derivadas dos exemplos