Behavior-Driven Development (BDD) com Specflow

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.

Test-Driven Development: uma visão geral

Conforme já mencionado, testes unitários são elaborados antes da implementação de classes, métodos e outras estruturas sujeitas a validações em projetos que seguem os princípios de TDD. Um dos motivos que justificam essa abordagem é a necessidade de evitar a execução de testes “viciados”, ou seja, com um resultado sempre satisfatório independemente da existência de falhas que tenham passado de forma despercebida no código.

A escrita de testes antes mesmo das codificações pressupõe um trabalho bem planejado, em que a organização do código favorece práticas como a separação de responsabilidades, uma alta coesão e um baixo acoplamento entre os diferentes elementos que compõem a aplicação (BOX 2).

São características típicas de testes unitários bem definidos:

· Rapidez na execução;

· Essas estruturas podem ser implementadas com facilidade, a partir de algum mecanismo concebido especificamente para este fim. No caso da plataforma .NET, frameworks como MS Test (BOX 3) e NUnit (BOX 4) representam as principais opções atualmente disponíveis;

· São automatizados e repetíveis, características estas que permitem sucessivas execuções a partir de IDEs e outras ferramentas gráficas;

· Podem ser reutilizados futuramente, com o intuito de avaliar se modificações introduziram erros em rotinas já verificadas anteriormente.

O trabalho em um projeto no qual são adotadas técnicas de TDD acontece seguindo um ciclo conhecido como Red-Green-Refactor (Figura 1), em que cada um desses termos equivale a uma fase da construção/execução de testes unitários:

· Red: um teste é definido no início do desenvolvimento, sem que a funcionalidade relacionada ao mesmo tenha sido implementada (o comum é que exista apenas um “esqueleto” de tal estrutura neste primeiro momento). A intenção nesta fase é que o teste realmente falhe (por isso o nome “Red”, em alusão à cor vermelha indicando um problema), de forma a garantir que o teste em questão não esteja “viciado”;

· Green: a funcionalidade é implementada da form ...