Pesquisa BDD E Cucumber

PESQUISA SOBRE BDD E CUCUMBER

BDD - Behaviour-Driven Development

É a forma de criar comportamentos testáveis e automatizados que agreguem valor para o cliente antes da existência do código-fonte, evitam defeitos baseados em comportamento e geram um conjunto de testes de regressão baseados nesses comportamentos.

No ano de 2006, Dan North e a ThoughtWorks criaram o JBehave aplicando os conceitos de Behaviour-Driven Development como proposta para resolver esse problema. BDD é baseado principalmente em Domain-Driven Design e Test-Driven Development. Envolve o negócio, teste de software, desenvolvimento e planejamento. O BDD é uma abordagem inovadora de teste que junta os dois mundos, em apenas um repositório, você mantém os testes de aceite automatizados de uma forma simples de ler para o cliente, desenvolvedores, QAs e demais membros da equipe e ao mesmo tempo esses testes são automatizados antes do desenvolvimento, formando um conjunto de testes de aceite que guiam o desenvolvimento e em seguida são usados como testes de regressão. Nessa abordagem, a documentação e o código de desenvolvimento evoluem sempre juntos. Mas na verdade o BDD envolve muito mais do que essa simples definição.

Os três princípios do BDD são:

1. O suficiente é suficiente: Não devemos automatizar tudo, mas sim tudo o que descreve o comportamento esperado do produto pelo cliente. O suficiente para desenvolver a solução. Mais do que isso é desperdício de esforço.

2. Entregar valor para os stakeholders: Entregue somente o que tem valor para o cliente, nada mais. Se o que estiver fazendo não agrega valor para o cliente ou não potencializar o valor entregue, pare de fazer isso.

3. Tudo é comportamento: Tudo que um software faz pode ser descrito como comportamento e explicado para qualquer pessoa que tenha o domínio do negócio. Não importa o nível de teste, o tipo de funcionalidade, sempre será descrito como comportamento.

BDD se apoia no uso de um vocabulário pequeno e bem específico. Dessa forma, minimiza “ruídos” na comunicação de forma que todos os interessados tanto de TI, quanto do negócio estejam alinhados.

Por apoiar todos os envolvidos e reduzir riscos de desenvolvimento inadequado, a venda da ideia para BDD costuma ser mais fácil do que para TDD. Embora, por envolver mais gente, seja mais trabalhoso de implantar.

Seguem abaixo as principais características de BDD:

• BDD usa testes como requisitos;

• BDD torna os testes mais elegantes;

• BDD torna os testes mais legíveis e sucintos;

• BDD torna os testes simples para pessoas de negócios;

• BDD consome menos tempo para escrever testes;

• BDD é documentação evolutiva;

• BDD é documentação executável;

• Critérios de aceite representam o valor do produto e não valor de documentação;

• BDD tecnicamente é teste de unidade, integração ou sistema, mas com valor de teste de aceite;

• BDD é teste que evita defeito não que encontra defeitos;

Todos os tipos de projetos podem usar BDD. Projetos web, desktop, mobile, em processos ágeis, em processos tradicionais, em empresas públicas e privadas, com ou sem QAs/Testadores. Porém, como foi citado anteriormente, o BDD não é uma técnica para automatizar todos os testes, mas sim aqueles que descrevem os comportamentos do sistema e garantir que eles estejam sempre funcionando. Não se devem automatizar todos os cenários possíveis com essa abordagem, pois vai se tornar um processo muito complexo modificar os testes no futuro. Se o projeto requer uma quantidade superior de qualidade, ou seja, para que não seja necessário que apenas o comportamento do sistema seja testado continuamente, vale a pena apostar em outras ferramentas e técnicas para testar os cenários que o cucumber não cobre por natureza, mas essas ferramentas podem ser complementares.

BDD colabora para que o desenvolvimento foque na entrega de valor, através da formação de um vocabulário comum, reduzindo a distância entre o Negócio e Tecnologia.

BDD garante uma documentação viva

BDD associa os benefícios de uma documentação formal, escrita e mantida pelo negócio, com testes de unidade que demonstram que essa documentação é efetivamente válida.

Na prática isso garante que a documentação deixa de ser um registro estático, que se converte em algo gradualmente ultrapassado, em um artefato “vivo” que reflete constantemente o estado atual de um projeto.

CUCUMBER

O Cucumber é uma ferramenta que pode executar documentação de funcionalidades escrita em texto puro.

Você escreve especificações sobre como uma determinada funcionalidade da sua aplicação deve ser, usando puro texto. O Cucumber executa testes em cima destas especificações.

Seguindo a filosofia do BDD, você deve escrever as especificações antes de implementar qualquer código. Você modela seu código a partir do comportamento esperado da aplicação.

O Fluxo de desenvolvimento com o Cucumber

Como já dito anteriormente, o Cucumber é uma ferramenta para BDD. Isso significa que espera-se que você escreva