Como é de conhecimento geral, o desenvolvimento de softwares em muitas organizações está marcado por pressões envolvendo entregas dentro de prazos extremamente curtos, equipes reduzidas e/ou modificações frequentes em requisitos (seja por necessidades do próprio negócio ou, até mesmo, por questões legais). Não será rara a ocorrência de problemas em um cenário desse tipo, com as dificuldades só aumentando quando não existir um processo de gerenciamento bem definido e flexível ou ainda, por dificuldades em compreender o que realmente os usuários precisam.

Diante de situações relativamente comuns como estas, diversas alternativas foram propostas com o intuito de organizar a forma como softwares são construídos. As metodologias ágeis representam uma das iniciativas mais populares atualmente neste sentido. Essas práticas procuram conciliar o tempo reduzido para as entregas com as mudanças praticamente certas ao longo de um projeto. Essas técnicas contemplam ainda uma série de recomendações que prezam a busca por mais qualidade e produtividade, assim como mecanismos que tentam promover uma melhora significativa na comunicação entre a equipe de TI e os responsáveis por solicitar um sistema.

XP (BOX 1) foi um dos primeiros métodos ágeis a contar com uma grande aceitação. Surgida ainda no final dos anos 1990, essa nova proposta foi pioneira em incentivar o uso de testes unitários automizados na verificação/validação de métodos, classes e outros tipos de construções típicos de sistemas orientados a objetos. Esse foco na execução de testes contribuiu inclusive para o surgimento da metodologia conhecida como TDD (Test-Driven Development).

O uso das técnicas de TDD em um projeto implica na escrita de testes unitários antes mesmo do código que virá a ser analisado. Quando empregado corretamente, este tipo de prática contribui não apenas para a obtenção sistemas bem estruturados (já que os testes são normalmente aplicados a porções não tão extensas de código), como também permite averiguar rapidamente se modificações efetuadas na aplicação produziram ou não efeitos colaterais.

Apesar dos benefícios decorrentes da adoção de TDD no desenvolvimento de novas soluções, os testes produzidos ao adotar essa metodologia foram normalmente escritos segundo as regras de uma plataforma de desenvolvimento específica. Este fato acaba por restringir o uso dessa prática a desenvolvedores, distanciando a elaboração de testes automatizados de uma linguagem facilmente compreensível por usuários do sistema. Outros profissionais envolvidos em um projeto e que não disponham de um grande know-how técnico (como Analistas de Testes, por exemplo) também podem ficar à margem deste processo.

O advento da metodologia conhecida como Behavior-Driven Development (BDD) forneceu meios que ajudam a superar essa limitação. Partindo de uma linguagem facilmente compreendida pela área de negócios, as práticas propostas por esta abordagem representam uma evolução das técnicas de TDD. O objetivo deste artigo é fornecer uma visão geral do funcionamento de BDD como metodologia de desenvolvimento. Além disso, será apresentando um exemplo de como este paradigma pode ser empregado em soluções .NET, fazendo uso para isto do framework SpecFlow.