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