Artigos .NET Behavior-Driven Development (BDD) com Specflow
Artigo do tipo Tutorial
Recursos especiais neste artigo:
Conteúdo sobre boas práticas
Porque esse artigo é útil
Este artigo tem por objetivo discutir a metodologia conhecida como Behavior Driven Development (ou simplesmente “BDD”), destacando como os conceitos propostos por este processo de desenvolvimento ágil podem ser adotados em projetos .NET. Partindo da elaboração de histórias que descrevem o comportamento esperado para um recurso dentro de um sistema, BDD procura aproximar as áreas de negócios e técnica por meio de uma linguagem simplificada, sem se prender a detalhes técnicos (quase sempre incompreensíveis para quem solicita uma nova funcionalidade). Tais histórias servem de base inclusive para a codificação de testes automatizados, algo que estaremos demonstrando no Visual Studio 2012, através de um exemplo que faz uso do framework 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.

BOX 1. XP

XP (abreviação do inglês “Extreme Programming”) é uma metodologia de desenvolvimento proposta pelo especialista em softwares Kent Beck, a qual que se caracteriza por uma forte ênfase na elaboração e execução contínua de testes unitários, bem como pela codificação em pares: uma dupla de desenvolvedores participa da implementação de uma ou mais funcionalidades, sendo que isto acontece em torno de um único computador, com a pessoa responsável por escrever o código sendo auxiliada pelo parceiro que a observa e a orienta conforme a evolução das atividades. Esta abordagem em que dois profissionais interagem em conjunto procura diminuir a incidência de falhas, assim como possibilitar uma melhor qualidade do código resultante.

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).

BOX 2. Separação de Responsabilidades, coesão e acoplamento

Separação de Responsabilidades (do inglês “Separation of Concerns”) é um princípio de desenvolvimento de sistemas que busca fornecer, através de uma série de recomendações, diretrizes que conduzam à obtenção de aplicações formadas por componentes mais coesos. O conceito de coesão, por sua vez, deve ser compreendido como a medida com a qual uma estrutura de software (classe ou componente) atende o objetivo inicial para o qual foi concebida. Uma alta coesão indica que o item que se está considerando não acumula responsabilidades além daquelas para as quais foi especificado, sendo esta uma característica perseguida por todos os projetos de software que procuram ser bem estruturados.

Acoplamento é um conceito empregado para determinar o grau de relacionamento entre diferentes partes que constituem uma aplicação. Um alto acoplamento resulta em um nível de alta dependência entre os diversos componentes envolvidos, fato este que pode levar a dificuldades na manutenção futura das funcionalidades consideradas. Logo, o ideal é que exista um baixo nível de acoplamento entre as estruturas que constituem um determinado sistema.

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.

BOX 3. MS Test

MS Test é um framework criado pela própria Microsoft para a elaboração de testes unitários. O Visual Studio possui uma excelente integração com esta ferramenta, disponibilizando inclusive templates para a codificação de testes baseados no MS Test.

BOX 4. NUnit

NUnit é um framework para a implementação de testes unitários na plataforma .NET. Esta solução se originou da ferramenta JUnit (uma das primeiras iniciativas voltadas à execução de testes automatizados em Java), possuindo total compatibilidade com o .NET Framework e contando com uma ampla base de desenvolvedores que empregam o mesmo nos mais variados projetos.

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 ...

Quer ler esse conteúdo completo? Tenha acesso completo