O BDD é escalável para projetos de médio a grande porte?

Em todos os sites que você lê sobre BDD (Behavior Driven Development), você encontra um bom exemplo muito simples, mostrando como é óbvio e fácil definir seus requisitos. Mas tentar implementar esse processo em um grande produto (não um exemplo de calculadora) me mostrou que as coisas podem ficar (ou ficarão) bem complexas e ilegíveis; especialmente solicitações de alteração em um momento posterior significa muito trabalho para corrigir os testes de integração para isso.

Então, eu estou me perguntando, o BDD realmente vale a pena? Isso resolve um problema que outras técnicas não!

Eu acho que um dos melhores recursos no BDD é o livro Specification by Example . Ele diz muito sobre como organizar testes de BDD e como eles devem ser escritos para que não causem tanto retrabalho quando os requisitos mudam.

Se as coisas ficarem complexas ou complicadas demais em seus testes, provavelmente você está fazendo algo errado. É o mesmo com o BDD e o TDD. Escrever bons testes é difícil e leva meses para ser aprendido.

Pode ajudar a perceber que o foco do BDD são as conversas . O BDD é realmente uma ferramenta de análise que fornece alguns testes de regressão como um bom subproduto.

Eu usei cenários em todos os tipos de níveis na conversa; desde a identificação de diferentes partes interessadas para ver se é provável que uma versão seja bem recebida, até a elaboração de como um módulo ou classe deve se comportar .

Existem algumas dicas e sugestões que posso sugerir para facilitar isso.

Se você nunca fez isso antes, isso vai mudar.

Qualquer coisa nova no domínio ou nos negócios provavelmente mudará. Você pode perceber que está nesse espaço se estiver falando dos cenários, questionando-os e os negócios disserem: "Oh, não tenho certeza". Esse é um bom sinal para parar de tentar fazer BDD e gerar algo para obter um feedback mais rápido, para ajudar a empresa a descobrir o que eles querem. Depois que as idéias se estabilizarem, os cenários podem ser escritos em retrospecto.

Todos os projetos têm algum aspecto novo, ou você não os faria.

Se você já fez isso antes, é chato.

Além dos aspectos novos e diferenciadores , os projetos geralmente têm alguns aspectos comoditizados, semelhantes aos já realizados. Por exemplo, se eu estivesse produzindo um novo celular, ele ainda precisaria fazer chamadas. "Fazer uma ligação" é um cenário tão conhecido que não precisaríamos conversar sobre isso. Da mesma forma, coisas como "login" ou mesmo "registro de usuário" são chatas.

Sempre que possível, use bibliotecas para elas e, em seguida, você não precisará escrever cenários em torno delas. Além disso, fazer os outros bits em primeiro lugar - têm um já-usuário conectado e trabalhar para fora o que logging ele está em para . É improvável que essas áreas sejam alteradas; portanto, você pode se safar dos testes manuais de qualquer maneira.

Se alguém já fez isso antes, conversar através de cenários pode ajudar.

Há um pouco entre onde temos requisitos específicos de domínio, coisas que são relativamente bem entendidas por alguém e onde a incerteza real está principalmente no escopo, em vez do comportamento real do sistema.

Conversar através de cenários pode ajudar a equipe de desenvolvimento a descobrir comportamento, aproveitar o conhecimento de um especialista e garantir que o comportamento conhecido e valioso seja capturado.

É aqui que o BDD funciona melhor. Minha dica é escrever os cenários mais interessantes na parte superior do arquivo de recursos (ou wiki, se você não estiver automatizando) e excluir os cenários duplicados ou fáceis de inferir como resultado.

Sempre que possível, use os cenários apenas como exemplos de como o aplicativo funciona . Por exemplo, se você quiser mostrar como a validação funciona, mostre alguns exemplos de como o aplicativo ajuda o usuário a preencher um formulário. Verifique se a validação é rigorosa usando o teste de unidade, que é muito mais fácil de manter e mais rápido de executar.

Leitura adicional

Se você está interessado nisso, aqui estão algumas coisas que escrevi que podem ajudar.

BDD nas grandes

Cynefin para desenvolvedores , que aborda essas três áreas com mais detalhes

Meus slides do tutorial , todos agradáveis ​​e anotados para você, cobrem toda a pilha também.

Criamos um projeto bastante complexo ( complexidade do domínio ) no outono passado e posso dizer honestamente que colocar o trabalho inicial no BDD salvou o projeto. Vi uma forte correlação entre a complexidade do domínio e os benefícios do BDD.

Deixe-me tirar uma coisa do caminho: testar regras comerciais complexas é difícil. A questão é: você deseja tentar se lembrar de todos os cenários malucos sempre que fizer uma alteração ou deseja que essa rede de segurança avise quando você violar as especificações. Passe o tempo inicial e elabore todos os cenários, anote-os e, eventualmente, escreva todos os testes para eles.

E quando você volta mais tarde tentando entender as coisas, ter essa especificação testável salva a vida.

BDD é um processo de desenvolvimento baseado em TDD (Test Driven Development) Aqui estão alguns dos prós e contras do TDD extraídos de minha experiência pessoal:

• TDD, garante que seu escopo esteja bem definido. Dessa forma, você projeta seus casos de teste primeiro. Assim, defina uma expectativa para o trecho de código que você deve escrever.
• TDD é uma maneira de proteger seu código. Suponha que você escreva uma função simples e, posteriormente, adicione alguma condição de comutação complexa nessa mesma função. Amanhã, se alguém quiser modificar essa função, ele poderá consultar o caso de teste. Se ele quiser alterar sua função, ele também precisará alterar o caso de teste (na maioria das vezes). Isso permite que ele entenda que havia um motivo por trás do que você escreveu.
• O TDD permite um desenvolvimento mais rápido de software. Cada um de nós teria enfrentado esse problema durante a codificação. Começamos com uma ideia. E lentamente perca o controle. Acabamos colocando trechos de código indesejados para lidar com alguns cenários. No TDD, você define as expectativas antecipadamente. Assim, você se restringe a desviar-se muito do objetivo.
• O TDD permite capturar possíveis erros antes do projeto ficar online. Isso tem a ver principalmente com a qualidade dos casos de teste que são escritos.

Contras:

• No início, o TDD pode ser um pouco complicado. Muitas pessoas não entendem o conceito de um caso de teste que impulsiona o desenvolvimento.
• TDD, às vezes pode levar a grandes esforços em manutenção. Isso tem a ver com casos de teste indesejados ou sem sentido.
• TDD deve ser tomado com uma pitada de sal. Nenhum desenvolvedor gosta de gastar tempo em algum caso de teste escrito por outra pessoa. Decifrar o significado do caso de teste às vezes pode causar uma grande dor de cabeça.

Trabalho em um projeto com mais de 900.000 linhas de código. E eu ainda sigo o BDD. Uma coisa importante que você precisa considerar é o número de possíveis erros que você pode detectar devido aos casos de teste. Daqui a alguns anos, você estará jurando pelo BDD!