Desenvolvimento Orientado para o Comportamento

Em 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. Olhando de cima, 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, desenolvedores, 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 das histórias 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 (Behavior-Driven Development): 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.

0_1501681310823_3572e970-7c08-4870-9b97-b11ffc9d4903-image.png

Por que BDD é diferente de TDD?

Enquanto o TDD foca mais no design do código, o BDD foca no negócio. Usamos TDD para criar um pedaço de uma funcionalidade que descrevemos com um cenário de BDD. Ou seja, descrevemos o que (comportamento) do sistema com cenários de critérios de aceite, mas quando vamos implementar seus detalhes e testar o como ele implementa essa funcionalidade, usamos TDD.

Em uma analogia, podemos dizer que usamos BDD para descrever que um carro deve acelerar e para isso descrevemos que quando acionamos o pedal do acelerador, o carro deve acelerar a tal velocidade, o velocímetro deve aumentar e que o indicador de giro do motor deve exibir o giro, mas quando vamos montar o motor devemos descrever com TDD tudo que está dentro do motor.

O exemplo acima ressalta algumas das vantagens do uso do BDD, entre elas é que o teste é auto explicativo, ou seja, qualquer pessoa que saiba ler português sabe o que será testado. Além disso, o teste está junto com o seu requisito, ou seja, o requisito e o teste nasceram juntos e caso um seja alterado o outro será também. Na verdade, neste tipo de abordagem, o teste é o requisito. Para que uma US esteja completa, como citamos anteriormente, o software deve ser aprovado por todos os critérios de aceite.

Importante mencionar que os testes descritos acima são apenas um exemplo, e futuramente vamos implementar técnicas que implementam o princípio DRY (Don’t Repeat Yourself), entre outros conceitos mais avançados das ferramentas de BDD.

Given (Dado): Representa a situação inicial do teste e pode ser considerado como a pré-condição.

When (Quando): Representa uma ação ou evento. Pode ser considerado como um procedimento.

Then (Então): Representa uma resposta, comportamento ou resultado esperado.

And (E): usado para extender o given, when ou then positivamente.

But (Mas): usado para extender o given, when ou then negativamente.

Quando não devo usar BDD?

Na verdade a pergunta correta seria “Como eu não devo usar BDD?”. 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 seu QAs/Testadores. Porem, 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 deve 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, 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.