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


22

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!


Pena, acho que esse problema é bastante construtivo, considerando que o BDD está se tornando mais popular recentemente.
DD

1
Se alguém com representante suficiente puder sugerir uma reabertura, seria uma ótima pessoa.
DD

Gostaria de voltar a abrir, mas você já aceitou a primeira resposta ...
MattDavey

1
Eu aceitei, pois foi fechado, então eu não conhecia mais respostas eram possíveis, mas im realmente interessted em mais relatos de experiência sobre isso, eu vou unaccept isso por agora
DD

2
ok ótimo :) Eu também acho que você deve editar a pergunta um pouco. Acho que sua pergunta é sobre a escalabilidade do BDD em grandes projetos. "O BDD é realmente tão bom" é subjetivo? "O BDD se adapta bem a grandes projetos" é um pouco mais objetivo.
22813 MattDavey

Respostas:


6

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.


3
TDD não é o mesmo, testar uma unidade predefinida nunca pode ficar tão complexo, a menos que você tenha unidades muito grandes com cheiro de código, mas os testes de integração devem testar a interação entre mais de uma unidade, uma funcionalidade total, isso permite que sua complexidade aumente linear aos requisitos, ainda assim você não pode quebrá-lo em pedaços menores, pois ele não seria mais um teste de atração se feito.
DD

Você pode anexar alguns testes BDD complicados e eu pude ver o que pode ser feito para simplificá-los.
Piotr Perak

Não é tão fácil, os que eu tenho aqui não são em inglês, eu precisaria traduzi-los, se eu encontrar um requisito que eu possa traduzir facilmente para o inglês, eu possa anexá-lo, mas ainda assim o código por trás também é um problema que seria muito grande para anexar aqui em uma postagem.
DD

Por que isso foi prejudicado? Dei um grande recurso que ajudará o OP a resolver seus problemas.
Piotr Perak

que não era eu, darei +1 para compensar, mas só posso fazer isso em 14 horas, pois usei todos os meus 30 votos para hoje.
DD

5

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.


Obrigado por esta resposta informativa, irei ler os links anexados
DD

3

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.


1

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!


2
Você deve elaborar mais sobre as diferenças entre BDD e TDD e onde a parte DDD entra.
Benjamin Gruenbaum

1
@BenjaminGruenbaum Idealmente, não há diferença entre BDD e TDD. BDD, quando seguido corretamente, é o mesmo que TDD! Portanto, não vi nenhum motivo para trazer a diferença como parte da resposta. Obrigado pela sugestão!
22413 Ricketyship

1
"O TDD permite um desenvolvimento mais rápido de software". houve algum estudo confirmando isso? Apenas curioso. Eu também mencionaria que a aceleração não é linear.
Den

2
@AlexandreMartins Hah, absolutamente! Muito mais importante reconhecer que você pode ter testes e cenários de baixa qualidade do que fingir que todos são bons na IMO.
Lunivore 27/02

2
@Livivore Sim, é isso que me incomoda no caso de BDD / TDD. Os casos de teste precisam ser fortes. Infelizmente, existe essa visão na comunidade de desenvolvimento de que, enquanto houver casos de teste, tudo bem! Uma vez vi um caso de teste em que havia uma linha sendo inserida em uma tabela usando uma instrução sql e o mesmo sendo afirmado na etapa seguinte! O desenvolvedor estava tentando testar a funcionalidade do oracle ?!
21713 Ricketyship
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.