Autor: Luís Sousa

Development

O Behaviour Driven Development (BDD) ou Desenvolvimento Orientado ao Comportamento é uma técnica de desenvolvimento ágil que junta algumas ideias do Domain Driven Design (DDD) às técnicas e princípios utilizados no Test Driven Development (TDD) orientando o desenvolvimento de software em função do comportamento, resolvendo assim alguns dos constrangimentos identificados na utilização desta última técnica.

O BDD surgiu da necessidade de colmatar algumas das falhas detectadas na utilização do TDD. Estas falhas surgem da falta de experiência de quem utiliza o TDD que faz com que não percebam o seu potencial. É frequente ouvir queixas dos programadores, alegando não saber o que deve ou não ser testado, que nome dar aos testes, até onde é que os seus testes devem ir, que a curva de aprendizagem é algo extensa, já para não falar da resistência que muitos têm, alegando que é uma perda de tempo “codificar” testes quando poderiam estar a implementar funcionalidades da aplicação. O problema não está propriamente no TDD, mas sim na forma como as pessoas utilizam esta técnica, focando-se em demasia nos testes e descurando, por vezes, o comportamento desejado para a aplicação.

O que o BDD veio mudar

O que o BDD veio mudar foi a forma como se aborda o desenvolvimento de software, dando mais ênfase aos comportamentos, passando estes a guiar o desenvolvimento da aplicação e não os testes. Contudo, os testes continuam a ser importantes. É muito útil ter testes automatizados que serão corridos sempre que se faça uma alteração na aplicação, assegurando que as novas funcionalidades estão bem implementadas e garantindo que o código existente não foi “estragado”. O que o BDD veio mudar refere-se ao excessivo foco que, por má prática, muitos utilizadores do TDD dão aos testes, desviando esse foco para o comportamento desejado/esperado da aplicação.

Para o BDD, uma clara definição de requisitos é portanto um ponto-chave. Para tal é utilizada uma linguagem ubíqua, presente no DDD, compreensível por todos os participantes (programadores, analistas, utilizadores de negócio, etc.) e que ajuda na priorização e validação dos comportamentos que a aplicação deverá ter. A linguagem, adequada ao negócio, utiliza vocabulário muito específico e restrito de forma a minimizar as más interpretações e falhas de comunicação entre os vários participantes no desenvolvimento de software.  

Os testes passam então a ser compostos por duas partes: a definição da funcionalidade a implementar e os cenários (casos de teste) que irão ajudar a validar essa funcionalidade. Desta forma, fica claro e perceptível para todos qual a vantagem que uma nova funcionalidade trará ao sistema. Os cenários (casos de teste) que acompanham as funcionalidades são uma peça fundamental para permitir validar o comportamento esperado da nova funcionalidade. A própria forma como estão redigidas as funcionalidades e os cenários permitem também que qualquer interveniente perceba do que se está a falar e mais facilmente detectar falhas/incorrecções nos próprios testes a efectuar.

A relação entre o BDD e o Test Driven Development

O BDD veio dar um forte contributo ao TDD, mudando o foco de desenvolvimento de software para os aspectos comportamentais do sistema em vez dos testes, ajudando a direccionar os programadores para o real valor que podem retirar do TDD, encurtando o próprio tempo de aprendizagem e fazendo com que Equipas novas no desenvolvimento ágil rapidamente acelerem utilizando estas técnicas.

Com o recurso a uma linguagem ubíqua o BDD consegue também encurtar o gap que separa os vários intervenientes no processo de desenvolvimento de software (programadores, analistas, pessoal não técnico e utilizadores de negócio, etc), minimizando assim alguns obstáculos anteriormente encontrados nas fases de especificação, desenho, implementação e validação do comportamento de um sistema.