BDD, do inglês Behavior Driven Development ou "desenvolvimento orientado por comportamento", se tornou um termo da moda entre desenvolvedores, analistas de qualidade e analistas de negócios. Apesar de suas fortes ideias, é geralmente mal compreendido. Seguidamente escutamos times que afirmam estar se utilizando de BDD, mas ao olhar mais de perto o que o time acaba fazendo é usar uma ferramenta de BDD para automação de testes - e não aplicando os conceitos em si. No final das contas, nós escutamos pessoas reclamando dessas ferramentas, e não sobre as ideias que inspiraram a criação dessas ferramentas. O resultado disso é uma série de queixas que vemos em diversos blogs pela internet - pessoas que passam a rejeitar toda a ideia por trás do BDD, tendo em vista que tentaram usar uma ferramenta sem antes mudar de atitude com relação à forma que desenvolvem software.
Freqüentemente escutamos essas 3 reclamações sobre BDD:
#1 O cliente não se importa com testes
Essa é a principal reclamação. Faz todo o sentido afirmar isso, visto que para o cliente o que realmente importa é um software que atenda às suas necessidades e que funcione. Se você começar uma discussão sobre testes, é muito provável que as pessoas envolvidas com o negócio vão acender a luz verde para se desligar do assunto. Além disso, a palavra teste infelizmente carrega consigo uma conotação negativa na comunidade de desenvolvimento de software.
Mas espere um pouco, nós estamos falando de BDD, que é desenvolvimento orientado por comportamento, e isso de nada tem a ver com testes. Testar é algo que você não pode fazer enquanto o software não existir. Testar significa verificar, e em BDD nós estamos tratando de especificar antes de mais nada.
BDD é uma atividade de design, onde você constrói partes da funcionalidade de maneira incremental guiado pelo comportamento esperado. Em BDD nós saímos da perspectiva orientada à testes e entramos na perspectiva orientada à especificações, o que significa que essa reclamação nasceu mal colocada.
#2 O cliente não quer escrever as especificações
Essa é a segunda reclamação mais usada. Vamos falar sobre ela em duas partes.
"O cliente deve escrever as especificações por conta própria"
Quem faz uso dessa reclamação está afirmando que é esperado que o cliente proponha a solução para o seu próprio problema - problema esse que o seu software é que deveria resolver.
Se o cliente escrever as especificações ele não irá se beneficiar de algo chamado diversidade cognitiva, e essa diversidade só aparece em grupos heterogêneos de pessoas trabalhando juntas.
Ele precisa do conselho de engenheiros que sabem os aspectos técnicos do problema que ele está tentando resolver. Ele também precisa do paradigma de um analista de qualidade o qual vai auxiliar na criação de cenários que ninguém pensou antes. Caso contrário, a solução na qual ele pensou pode ser muito mais complexa do que ela precisa ser.
É injusto reclamar sobre algo que nós, como o time de desenvolvimento, é que deveríamos ser os responsáveis por ajudar nossos clientes.
"O cliente precisa interagir diretamente com a ferramenta"
Essa não é a ideia. O que ele realmente precisa fazer, é prover ao time informações sobre o problema que ele quer resolver, e juntos podem pensar nos exemplos concretos que vão nortear o processo de desenvolvimento.
#3 Você consegue alcançar o mesmo resultado sem uma linguagem específica de domínio (DSL)
Esse argumento é encontrado comumente entre desenvolvedores. A maior parte desses desenvolvedores argumenta que não existe um benefício real em acrescentar mais essa camada - que descreve comportamento em linguagem natural - visto que ela apenas adiciona complexidade e faz com que o conjunto de testes fique lento.
Se nós olharmos essa reclamação focando em uma tech stack em Ruby, isso geralmente significa que ao invés de usar o Cucumber, você pode usar o Capybara + RSpec para obter o mesmo benefício e ainda por cima ter uma melhor performance ao rodar seus testes.
A verdade é que essa comparação não faz sentido. É como comparar maçãs e laranjas: são coisas totalmente distintas.
O benefício em se utilizar de uma linguagem específica de domínio que pessoas do negócio podem ler - como as especificações que escrevemos no Cucumber neste caso - vai além do que a perspectiva de um desenvolvedor é capaz de compreender. Não se trata de código, se trata de aprimorar a comunicação entre todos os membros do time.
Ou seja, é ter os analistas de negócio dialogando com os desenvolvedores e analistas de qualidade, todos eles aprimorando aquele único arquivo que é uma maneira não abstrata de demonstrar ideias - o arquivo das especificações, o qual descreve todos os cenários da funcionalidade. Além disso, estarão usando suas diferentes capacidades cognitivas para juntos pensarem em qual o melhor caminho para transformar uma especificação na concretização das necessidades do negócio.
Um caso de sucesso usando BDD
O quão complicado seria para você explicar para uma criança de 3 anos de idade como uma transação bancária funciona? O mesmo desafio se aplica durante o desenvolvimento de software, visto que o domínio do cliente pode, por diversas vezes, ser bastante vago e nebuloso para o time de desenvolvimento.
O ser humano precisa de exemplos para compreender um tópico. Exemplos reais são uma excelente forma de se comunicar, e no nosso dia-a-dia nós usamos eles, sem nem mesmo perceber. Ao trabalhar com exemplos reais nós nos comunicamos melhor, pois as pessoas serão capazes de se relacionar com eles mais facilmente.
Isso tudo é muito mais perceptível quando o domínio do negócio é complexo.
Um bom exemplo disso é um projeto no qual trabalhamos, de um banco de investimentos. Como é de se esperar em um domínio desses, as terminologias eram muito complicadas, tornando um tanto quanto difícil a vida dos desenvolvedores na hora de manter um diálogo com os analistas de negócios do banco.
No intuito de nos comunicarmos melhor, parte do nosso processo era, antes de começar uma estória, ter o par de desenvolvedores fazendo uma rápida chamada de áudio/vídeo com o analista de negócios responsável por ela. Esse analista por sua vez compartilhava com os desenvolvedores o arquivo com as especificações - também conhecido como feature file - o qual continha todos os cenários nos quais ele pensou.
Visto que neste time não haviam analistas de qualidade, é importante mencionar que durante essa sessão um dos desenvolvedores deveria manter um pensamento mais alinhado com o de um analista de qualidade - focando em aprimorar os cenários já criados e sugerindo a criação de cenários que ainda não foram explorados - enquanto o outro desenvolvedor focaria mais nos desafios técnicos da implementação, como por exemplo sugerir mover um cenário para uma especificação à nível de código - que oferece um feedback mais rápido no conjunto de testes. Todos também podiam sugerir mudanças aos passos de um cenário, caso isso fizesse mais sentido à compreensão de todos.
Ao utilizar esse processo os analistas de negócios expandiam o seu conhecimento ao compreender melhor os desafios técnicos de cada cenário e os desenvolvedores conseguiam ter uma ideia mais clara das necessidades do negócio, facilitando na compreensão do que realmente precisava ser desenvolvido. Além disso, sempre que mudanças fossem necessárias, apenas aquele único pedaço de informação seria mexido, o que significa que todo o time estaria sempre atualizado.
Indo mais fundo no assunto
Para finalizar, a principal ideia por trás do BDD é o seu foco em prevenir falhas de comunicação, o que significa ter todos no time comunicando de maneira mais frequente, melhor e baseados em exemplos reais - não somente abstrações e requisitos imperativos.
Esperamos que este artigo ajude as pessoas a entenderem melhor os benefícios por trás do BDD - e que fique claro que as ferramentas de BDD são apenas complementares à essa metodologia ágil completa que o BDD é.
Se você quer ir mais a fundo no assunto, nós sugerimos as seguintes fontes:
- "Specification by Example" by Gojko Adzic
- "The RSpec Book" by David Chelimsky
- "The Cucumber Book" by Matt Wynne and Aslak Hellesoy
- Dave Astels and Steven Baker on RSpec and Behavior-Driven Development
- Gojko on BDD: Busting the Myths
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.