Quais são as principais diferenças entre TDD e BDD?
https://stackoverflow.com/questions/2509
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
O Desenvolvimento Orientado a Testes tem sido a moda na comunidade .NET nos últimos anos.Recentemente, ouvi reclamações na comunidade ALT.NET sobre o BDD.O que é?O que o torna diferente do TDD?
Solução
Eu entendo que o BDD é mais sobre especificação que testando.Ele está vinculado ao Domain Driven Design (você não adora essas siglas *DD?).
Está ligado a uma certa maneira de escrever histórias de usuários, incluindo testes de alto nível.Um exemplo por Tom dez Thij:
Story: User logging in
As a user
I want to login with my details
So that I can get access to the site
Scenario: User uses wrong password
Given a username 'jdoe'
And a password 'letmein'
When the user logs in with username and password
Then the login form should be shown again
(Em seu artigo, Tom executa diretamente esta especificação de teste em Ruby.)
O papa do BDD é Dan Norte.Você encontrará uma ótima introdução em seu Apresentando o BDD artigo.
Você encontrará uma comparação entre BDD e TDD neste vídeo.Também uma opinião sobre o BDD como "TDD feito da maneira certa" por Jeremias D.Moleiro
Atualização de 25 de março de 2013
O vídeo acima está desaparecido há algum tempo.Aqui está um recente de Llewellyn Falco, BDD versus TDD (explicado).Acho sua explicação clara e objetiva.
Outras dicas
Para mim, a principal diferença entre BDD e TDD é o foco e o texto.E as palavras são importantes para comunicar sua intenção.
TDD direciona o foco para testes.E como no “velho mundo em cascata” os testes ocorrem após a implementação, essa mentalidade leva a uma compreensão e comportamento errados.
O BDD direciona o foco para o comportamento e as especificações e, portanto, as mentes em cascata ficam distraídas.Portanto, o BDD é mais facilmente entendido como prática de design e não como prática de teste.
Parece haver dois tipos de BDD.
O primeiro é o estilo original que Dan North discute e que causou a criação dos frameworks de estilo xBehave.Para mim, esse estilo é aplicável principalmente para testes de aceitação ou especificações de objetos de domínio.
O segundo estilo é o que Dave Astels popularizou e que, para mim, é uma nova forma de TDD que traz alguns benefícios sérios.Ele se concentra no comportamento ao invés de testes e também em pequenas classes de teste, tentando chegar ao ponto onde você tem basicamente uma linha por método de especificação (teste).Este estilo se adapta a todos os níveis de teste e pode ser feito usando qualquer estrutura de teste de unidade existente, embora estruturas mais recentes (estilo xSpec) ajudem a focar no comportamento em vez de testar.
Há também um grupo BDD que pode ser útil:
Desenvolvimento Orientado a Testes é uma metodologia de desenvolvimento de software que testa primeiro, o que significa que requer a escrita do código de teste antes de escrever o código real que será testado.Nas palavras de Kent Beck:
O estilo aqui é escrever algumas linhas de código, depois um teste que deve ser executado ou até melhor, para escrever um teste que não será executado e, em seguida, escreva o código que o fará executar.
Depois de descobrir como escrever uma pequena parte do código, agora, em vez de apenas codificar, queremos obter feedback imediato e praticar "codificar um pouco, teste um pouco, codifique um pouco, teste um pouco". Então, escrevemos imediatamente um teste para isso.
Portanto, TDD é uma metodologia técnica de baixo nível que os programadores usam para produzir código limpo que funcione.
Desenvolvimento Orientado ao Comportamento é uma metodologia que foi criada com base em TDD, mas evoluiu para um processo que não diz respeito apenas a programadores e testadores, mas sim a toda a equipe e a todos os stakeholders importantes, técnicos e não técnicos.O BDD começou com algumas perguntas simples que o TDD não responde bem:quantos testes devo escrever?O que devo realmente testar – e o que não devo?Quais dos testes que escrevo serão de fato importantes para o negócio ou para a qualidade geral do produto, e quais são apenas meu excesso de engenharia?
Como você pode ver, essas questões exigem colaboração entre tecnologia e negócios.As partes interessadas do negócio e os especialistas do domínio muitas vezes podem dizer aos engenheiros que tipo de testes seriam úteis, mas apenas se os testes forem de alto nível que tratem de aspectos importantes do negócio.O BDD chama esses testes de negócios de “exemplos”, como em “diga-me um exemplo de como esse recurso deve se comportar corretamente” e reserva a palavra “teste” para verificações técnicas de baixo nível, como validação de dados ou testes de integrações de API.A parte importante é que enquanto testes só pode ser criado por programadores e testadores, exemplos podem ser coletados e analisados por toda a equipe de entrega – por designers, analistas e assim por diante.
Em uma frase, uma das melhores definições de BDD que tenho encontrado Até agora, o BDD é sobre "conversas com especialistas em domínio e usar exemplos para obter uma compreensão compartilhada do comportamento desejado e descobrir incógnitas". A parte da descoberta é muito importante.À medida que a equipe de entrega coleta mais exemplos, ela começa a entender cada vez mais o domínio do negócio e, assim, reduz a incerteza sobre alguns aspectos do produto com os quais tem que lidar.À medida que a incerteza diminui, a criatividade e a autonomia da equipa de entrega aumentam.Por exemplo, agora eles podem começar a sugerir seus próprios exemplos que os usuários empresariais não consideravam possíveis devido à sua falta de conhecimento técnico.
Agora, conversar com especialistas de negócios e domínio parece ótimo, mas todos nós sabemos como isso muitas vezes acaba na prática.Comecei minha jornada com tecnologia como programador.Como programadores, somos ensinados a escrever código—algoritmos, padrões de design, abstrações.Ou, se você é um designer, você é ensinado a projeto—organize informações e crie interfaces bonitas.Mas quando conseguimos nossos empregos de nível básico, nossos empregadores esperam que "agregamos valor aos clientes". E entre esses clientes pode ser, por exemplo ...um banco.Mas eu não sabia quase nada sobre serviços bancários – exceto como diminuir com eficiência o saldo da minha conta.Então eu teria que traduzir de alguma forma o que é esperado de mim em código...Eu teria que construir uma ponte entre o setor bancário e meu conhecimento técnico se quiser agregar algum valor.O BDD me ajuda a construir essa ponte sobre uma base estável de comunicação fluida entre a equipe de entrega e os especialistas do domínio.
Saber mais
Se você quiser ler mais sobre BDD, escrevi um livro sobre o assunto. “Escrevendo ótimas especificações” explora a arte de analisar requisitos e ajudará você a aprender como construir um ótimo processo de BDD e usar exemplos como parte central desse processo.O livro fala sobre a linguagem onipresente, coletando exemplos e criando as chamadas especificações executáveis (testes automatizados) a partir dos exemplos – técnicas que ajudam as equipes de BDD a entregar software excelente dentro do prazo e do orçamento.
Se você estiver interessado em comprar “Escrevendo ótimas especificações”, você pode economizar 39% com o código promocional 39nicieja2 :)
Eu experimentei um pouco com a abordagem BDD e minha conclusão prematura é que o BDD é adequado para implementação de casos de uso, mas não nos detalhes subjacentes.TDD ainda arrasa nesse nível.
O BDD também é usado como ferramenta de comunicação.O objetivo é escrever especificações executáveis que possam ser compreendidas pelos especialistas do domínio.
Parece-me que o BDD tem um escopo mais amplo.Quase implica que o TDD seja usado, que o BDD seja a metodologia abrangente que reúne as informações e os requisitos para usar, entre outras coisas, práticas de TDD para garantir feedback rápido.
Com meu conhecimento mais recente em BDD quando comparado ao TDD, o BDD se concentra em especificar o que acontecerá a seguir, enquanto o TDD se concentra em configurar um conjunto de condições e depois observar o resultado.
O Desenvolvimento Orientado a Comportamento parece focar mais na interação e comunicação entre Desenvolvedores e também entre Desenvolvedores e testadores.
O artigo da Wikipedia tem uma explicação:
Desenvolvimento baseado em comportamento
Porém, não estou praticando BDD.
Considere que o principal benefício do TDD é o design.Deveria ser chamado de Design Orientado a Testes.BDD é um subconjunto do TDD, chame-o de Behavior Driven Design.
Agora considere uma implementação popular de TDD – Teste de Unidade.As unidades em testes unitários são normalmente um pedaço de lógica que é a menor unidade de trabalho que você pode fazer.
Ao reunir essas unidades de maneira funcional para descrever o comportamento desejado para as máquinas, você precisa entender o comportamento que está descrevendo para a máquina.O Behavior Driven Design se concentra em verificar a compreensão dos implementadores sobre os casos de uso/requisitos/qualquer coisa e verifica a implementação de cada recurso.BDD e TDD em geral servem ao importante propósito de informar o design e ao segundo propósito de verificar a exatidão da implementação, especialmente quando ela muda.O BDD bem feito envolve biz e dev (e qa), enquanto o teste de unidade (possivelmente visto incorretamente como TDD em vez de um tipo de TDD) normalmente é feito no silo de desenvolvimento.
Eu acrescentaria que os testes de BDD servem como requisitos de vida.
BDD é em grande parte TDD bem feito.No entanto, há um valor adicional que o BDD oferece.Aqui está um link sobre isso:
Aqui está o instantâneo rápido:
TDD é apenas o processo de testar o código antes de escrevê-lo!
DDD é o processo de ser informado sobre o Domínio antes de cada ciclo de toque no código!
BDD é uma implementação do TDD que traz alguns aspectos do DDD!
Espero que ajude!
Diferença entre desenvolvimento orientado a testes (TDD) e desenvolvimento orientado a comportamento (BDD)
O BDD concentra-se no aspecto comportamental do sistema, e não no
aspecto de implementação do sistema no qual o TDD se concentra.O BDD dá uma compreensão mais clara sobre o que o sistema deve fazer
da perspectiva do desenvolvedor e do cliente.Somente TDD
dá ao desenvolvedor uma compreensão do que o sistema deve fazer.O BDD permite que o desenvolvedor e o cliente trabalhem juntos para análises de requisitos contidas no código -fonte do sistema.
Não há diferença entre TDD e BDD.exceto que você pode ler melhor seus testes e usá-los como requisitos.Se você escrever seus requisitos com as mesmas palavras que escreve testes BDD, poderá vir do seu cliente com alguns de seus testes definidos e prontos para escrever código.
