BDD: Requisitos Executáveis

O problema

Não importa se seu background é Agil, Iterativo, Waterfall ou Tradicional. Uma coisa é certa e todos concordamos: Requisitos excelentes combinados a uma arquitetura perfeitamente executada é uma ótima fórmula para o sucesso. Inicialmente, a fórmula parece ser simples. E é! O problema está em sua execução. Como saber se estamos exagerando nos requisitos e no design? Em outras palavras: quão profundos (ou superficiais) os requisitos devem ser para serem o bastante para um encaixe perfeito entre negócio e tecnologia?

A quantidade certa de cada ingrediente nesta fórmula tem assombrado a comunidade de desenvolvimento de software desde os tempos do COBOL até os dias de Internet/Cloud/.Net/Java/Ruby/Python/PHP de hoje. Esse mistério precisa ser desvendado!

Uma solução

Uma solução para este dilema pode ser encontrado em metodologias ágeis. Se fizer esta pergunta para um “agilista” a resposta será, na maioria dos casos: evite BDUF (Big Design Up Front). Faz sentido. Uma das características de requisitos é que eles tem a tendência de mudar. Portanto, se você demorar demais definido seus requisitos e arquitetura, tão logo você esteja pronto para iniciar a codificação, adivinhe o que acontece? Os danandos dos requisitos decidem mudar!

Bem… então temos um bom começo! Evitar BDUF! Mas esta é uma abordagem restritiva, não prescritiva. É ótimo saber o que NÃO fazer. Mas o que DEVEMOS fazer? Bem… mais uma vez os “agilistas” dirão: TDD é o caminho, irmão: vá e comece pelos testes. Novamente, uma grade diretiva, dessa vez bem prescritiva… mas completa? Sinto-me na obrigação de responder: não. Infelizmente, saber que os testes devem ser escritos antes da implementação em si é parte do “caminho para a perfeição”. TDD é fantástico: concordo com todas as minhas forças. Basicamente força o desenvolvedor a escrever código utilizando componentes desacoplados. Se a arquitetura seguir boas práticas comprovadas, design patterns e bom e velho bom senso, melhor ainda. Porém, uma última pergunta perdura: O QUE deve-se testar?

Vejo algumas mãos levantadas na audiência? Ah, sim. O senhor, por favor pode falar:

- Bem, Daniel, é claro! A resposta está nos requisitos. O desenvolvedor deve ler os requisitos, entender a necessidade de negócio e desenhar os testes de acordo com os requisitos.

Muto bem! Excelente sugestão. Mas resta um porém na seguinte combinação de palavras: “entender a necessidade de negócio”. Desenvolvedores são, geralmente, um grupo de indivíduos cartesianos. Vivemos em um mundo de zeros e uns, “Trues” e “Falses”, “ifs” e “elses”. Requisitos de negócio precisam identificar claramente a necessidade do cliente, mas se não forem escritos muito cuidadosamente, a ambiguidade se prolifera e o resultado vai acabar parecendo com o antigo, mas ainda muito verdadeiro desenho do “balanço na árvore”.

Ah, e mais um detalhe: e a rastreabilidade? Qual frase dos paragráfos da especificação clássica de requisitos é rastreável ao código que precisa ser revisado sempre que algo muda? Difícil, não é?

A solução

Mutio bem: diversas abordagens para definir requistos não ambíguos, verificáveis, atingíveis e específicos tem sido o objeto de muitos artigos, metodologias e frameworks. De agora em diante, vou focar em uma metodologia/framework que tem funcionado impressionantemente bem na minha experiência: Behavior Driven Development (ou BDD). O BDD tenta diminuir a distância entre os analistas de requisitos e desenvolvedores especificando uma “linguagem” bem definida. Esta “linguagem” é, ao mesmo tempo, natural e específica. É claramente entendível por stakeholders técnicos e de negócio e descrevem o comportamenteo de um sistema. Por exemplo:

Funcionalidade: Pedidos
  De modo a comprar um item
  Como um cliente
  Eu quer ser capaz de fazer pedidos


Cenário
: Adicionar um item ao carrinho de compras
 
Dado
que eu tenha selecionado um item
 
E
eu tenha informado a sua quantidade
 
Quando
eu pressionar o botão "adicionar ao carrinho"
 
Então
o item deve ser adicionado ao carrinho
 
E o valor total do carrinho deve ser incrementado da quantidade do item multiplicada pelo seu valor


O texto certamente parece ser não ambíguo, verificável, atingível e específico, não é?



E se cada uma destas linhas do cenário se transformasse em um passo específico em um test case N/J/x/Unit, a partir do qual arquitetura e código pudessem ser derivados, a-lá TDD? Não seria fantástico? Este e exatamente o objetivo do BDD.



Próximos passos



Acho que isto já é o bastante para justificar um par de artigos no futuro (próximo) que irá clarificar e exemplificar ainda mais o BDD. Como meu background é em .Net, vou fornecer exemplos em C# usando uma implementação muito bacana de BDD específica de .Net baseada no Cucumber: o Specflow, um projeto open source patrocinado pela TechTalk.

BDD: Executable Requirements

 

The problem

It doesn’t matter if your background is Agile, Iterative, Waterfall or Traditional. One thing is certain and we all agree: Excellent requirements combined with perfectly executed architecture is a great formula for success. At a first glance, the formula is simple… and it is! The problem is in the execution. How do we know we are being too heavy handed on requirements and design? In order words: how deep (or shallow) must the requirements be in order to be enough and how much design is needed for a perfect fit between business and technology?

The right amount of each ingredient of this formula has been haunting the development community since COBOL times and is still relevant in our Internet/Cloud/.Net/Java/Ruby/Python/PHP days… the mystery must be solved!

A solution

One solution to this dilemma can be found in agile methodologies. If you ask an agile methodologist the ingredient question, the answer will be, in most cases: avoid BDUF (Big Design Up Front). And it makes sense. One of the characteristics of requirements is that they tend to change. So if you take too much time in defining your requirements and architecture, as soon as you are ready to start implementing… guess what? Those pesky requirements decided to change!

So that’s a good start! Avoid BDUF! But that’s not a prescriptive approach, it’s restrictive. It’s great to know what we should NOT do. But what SHOULD we do? Well… again, agilists will say: TDD is the way, my brother … go forth and test first! Again… another great directive… and that’s very prescriptive… but is it complete? Hmmm… I’ll have to answer: no. Unfortunately, knowing that tests should be written before the actual implementation is part of the “path to perfection”. TDD is fantastic, I agree wholeheartedly. It practically forces the developer to write code using decoupled components. If the architecture follows industry-proven best practices, design patterns and good old common sense, it’s even better.  But one last question remains: WHAT should we test?

Do I see some hands raised in the audience? Oh, you, sir, please go ahead:

- Well, Daniel, of course. The answer is in the requirements. The developer should look up the requirements, understand the business need and design the tests accordingly.

Very well! That’s an excellent suggestion. But there’s a catch. It lies in the following word combination: “understand the business need”. Developers are, generally, a homogeneously Cartesian group of individuals. We live in a world of “0s” and “1s”, “Trues” and “Falses”, “ifs” and “elses”. Business level requirements may clearly identify a client need, but if they are not very carefully worded, ambiguity proliferates and the result may be like the age old, but too true “tire swing” cartoon.

Oh… and another catch: what about traceability? Which sentence of a classic requirement specification (set of) paragraphs traces to the code that needs to be reviewed whenever something changes? Tough, eh?

The solution

Well, several approaches to define unambiguous, verifiable, attainable and specific requirements have been subject of numerous papers, methodologies and frameworks. From now on, I’ll focus on a framework/methodology that has been working amazingly well in my experience: Behavior Driven Development (or BDD). BDD tries to bridge the gap between requirements analysts and developers by specifying a well defined “language”. This “language” is, at the same time, natural and specific. It is clearly understood by both business and technical-type stakeholders and describes system behavior. Here’s an example:

Feature: Order Placement	
  In order to purchase an item
  As a customer
  I want to be able to place orders


Scenario
: Add item to cart
 
Given
I have selected an item
 
And
I have provided its quantity
 
When
I press the "add to cart" button
 
Then
the item should be added to the cart
 
And the cart's total amount should be incremented by the selected item quantity multiplied by its price


It surely looks unambiguous, verifiable, attainable and specific enough, doesn’t it?



What if each one of those scenario lines became a specific step in a test case, from which architecture and code would be derived, a-la TDD? Wouldn’t it be fantastic? That’s exactly what BDD is about.



Next steps



I think this is just enough information to justify a couple of (near) future entries that will further clarify and exemplify BDD. Those entries will be a bit biased, though. Since my background is basically .Net, I will provide examples in C# using a beautifully implemented .Net-specific Cucumber-based BDD implementation: Specflow, an open source project sponsored by TechTalk.



See you in a bit!