Quais são as principais diferenças entre TDD e BDD?

votos
119

Test Driven Development tem sido a raiva na comunidade .NET para os últimos anos. Recentemente, ouvi murmúrios na comunidade ALT.NET sobre BDD. O que é isso? O que o torna diferente de TDD?

Publicado 05/08/2008 em 16:58
fonte usuário
Em outras línguas...                            


15 respostas

votos
94

Eu entendo BDD ser mais sobre a especificação de testes . Ela está ligada a Domain Driven Design (você não ama esses * DD siglas?).

Ela está ligada com uma certa maneira de escrever histórias de usuários, incluindo testes de alto nível. Um exemplo de 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 passa a executar diretamente esta especificação de teste em Ruby.)

O papa de BDD é Dan Norte . Você vai encontrar uma grande introdução em seu BDD Apresentando artigo.

Você vai encontrar uma comparação de BDD e TDD neste vídeo . Também uma opinião sobre BDD como "TDD feito à direita" por Jeremy D. Miller

25 março de 2013 atualização

O vídeo acima foi ausente por um tempo. Aqui é recente por Llewellyn Falco, BDD vs TDD (explicado) . I encontrar a sua explicação clara e ao ponto.

Respondeu 05/08/2008 em 17:36
fonte usuário

votos
17

Para mim principal diferença entre BDD e TDD é foco e redação. E as palavras são importantes para comunicar a sua intenção.

TDD dirige concentrar em testes. E uma vez que em testes de "cachoeira do velho mundo" vêm após a implementação, em seguida, essa mentalidade leva a compreensão e comportamento errado.

BDD direciona o foco no comportamento e especificação, e mentes de modo cachoeira são distraídos. Então BDD é mais facilmente entendida como prática de projeto e não como prática de teste.

Respondeu 08/09/2008 em 19:36
fonte usuário

votos
13

Parece haver dois tipos de BDD.

O primeiro é o estilo original que Dan Norte discute e que causou a criação de quadros de estilo xBehave. Para mim, este estilo é aplicável principalmente para testes de aceitação ou especificações contra objetos de domínio.

O segundo estilo é o que Dave Astels popularizado e que, para mim, é uma nova forma de TDD que tem alguns benefícios graves. Centra-se sobre o comportamento ao invés de testes e também classes de teste pequenas, tentando chegar ao ponto onde você tem basicamente uma linha por método de especificação (teste). Este estilo combina com todos os níveis de testes e pode ser feito usando qualquer framework de testes unitários existente embora os quadros mais recentes (estilo xSpec) ajudar a focar um comportamento ao invés de testes.

Há também um grupo BDD que podem ser úteis:

http://groups.google.com/group/behaviordrivendevelopment/

Respondeu 10/09/2008 em 17:00
fonte usuário

votos
6

Eu experimentei um pouco com a abordagem BDD e minha conclusão prematura é que BDD é bem adequado para usar a execução caso, mas não sobre os detalhes subjacentes. TDD ainda balançar a esse nível.

BDD também é usado como uma ferramenta de comunicação. O objetivo é escrever especificações executáveis ​​que podem ser entendidos pelos peritos do domínio.

Respondeu 27/08/2008 em 21:59
fonte usuário

votos
5

Driven Development-Test é uma metodologia de desenvolvimento de software de teste-primeiro, o que significa que ele requer escrever código de teste antes de escrever o código real que será testado. Nas palavras de Kent Beck:

O estilo aqui é para escrever algumas linhas de código, em seguida, um teste que deve ser executado, ou melhor ainda, escrever um teste que não será executado, em seguida, escrever o código que vai fazê-lo funcionar.

Depois de descobrir como escrever um pequeno pedaço de código, agora, em vez de apenas codificação em, queremos obter feedback imediato e prática "código um pouco, testar um pouco, código um pouco, testar um pouco." Então, nós imediatamente escrever um teste para ele.

Então TDD é um baixo nível, metodologia técnica que programadores usam para produzir código limpo que funciona.

Behavior Driven Development é uma metodologia que foi criado com base em TDD, mas evoluiu para um processo que não dizem respeito apenas a programadores e testadores, mas lida com toda a equipe e todas as partes interessadas importantes, técnica e não técnica. BDD começou de algumas perguntas simples que TDD não responde bem: quanto testes que eu deveria escrever? O que eu realmente deve testar-e o que não deveria? Qual dos testes que eu escrevo será de fato importante para o negócio ou para a qualidade global do produto, e que são apenas o meu excesso de engenharia?

Como você pode ver, estas questões exigem colaboração entre tecnologia e negócios. Os atores empresariais e especialistas de domínio muitas vezes pode dizer engenheiros que tipo de testes soam como eles seriam testes, mas útil apenas se os testes são de alto nível que lidam com aspectos importantes do negócio. BDD chama tais “exemplos,” Testes de negócios-como em “diga-me um exemplo de como esse recurso deve se comportar corretamente”, e reserva-se o palavra “teste” de baixo nível, verificações técnicas, tais como validação de dados ou integrações testes de API. A parte importante é que, enquanto os testes só podem ser criados por programadores e testadores, exemplos podem ser coletadas e analisadas pela entrega toda equipe-por designers, analistas, e assim por diante.

Em uma frase, uma das melhores definições de BDD tenho encontrado até agora é que BDD é sobre “ter conversas com especialistas em domínio e usando exemplos para obter uma compreensão compartilhada do comportamento desejado e descobrir incógnitas.” A parte descoberta é muito importante . Como a equipe de entrega recolhe mais exemplos, eles começam a compreender o domínio do negócio cada vez mais e, assim, reduzem sua incerteza sobre alguns aspectos do produto que eles têm de lidar. Como a incerteza diminui, criatividade e autonomia do aumento equipe de entrega. Por exemplo, eles podem agora começar a sugerir seus próprios exemplos que os usuários de negócios não pensaram eram possíveis por causa de sua falta de experiência de tecnologia.

Agora, ter conversas com os especialistas em negócios e domínio soa muito bem, mas todos nós sabemos como isso muitas vezes acaba na prática. Comecei minha jornada com tecnologia como um programador. Como programadores, somos ensinados a escrever código -algorithms, padrões de projeto, abstrações. Ou, se você é um designer, você é ensinado a desenhar-organize informações e criação de interfaces bonitas. Mas quando temos nossos empregos de nível de entrada, nossos empregadores esperam de nós "entregar valor aos clientes." E entre os clientes pode ser, por exemplo ... um banco. Mas eu poderia saber quase nada sobre a operação bancária, exceto como diminuir de forma eficiente saldo da minha conta. Então eu teria que traduzir de alguma forma o que se espera de mim em código ... eu teria que construir uma ponte entre banca e meu conhecimento técnico se eu quiser entregar qualquer valor. BDD me ajuda a construir tal ponte sobre uma base estável de comunicação fluida entre a equipe de entrega e os especialistas de domínio.

Saber mais

Se você quiser ler mais sobre BDD, eu escrevi um livro sobre o assunto. “Escrever Grandes Especificações” explora a arte de analisar os requisitos e irá ajudá-lo a aprender a construir um grande processo de BDD e usar exemplos como parte essencial desse processo. O livro fala sobre a linguagem ubíqua, recolhendo exemplos, e criando os chamados especificações executáveis (testes automatizados) para fora dos exemplos de técnicas que ajudam as equipes de BDD entregar grande softeware no tempo e no orçamento.

Se você está interessado em comprar “Escrever Grandes Especificações”, você pode economizar 39% com o código promocional 39nicieja2 :)

Respondeu 12/02/2017 em 16:43
fonte usuário

votos
2

Considere o principal benefício de TDD para ser design. Ele deve ser chamado Projeto Test Driven. BDD é um subconjunto de TDD, chamá-lo Behavior Driven Design.

Agora considere uma implementação popular de TDD - Unidade de Teste. As Unidades em Unidade de Teste são tipicamente um pouco de lógica que é a menor unidade de trabalho que você pode fazer.

Quando você colocar essas unidades juntas de uma forma funcional para descrever o comportamento desejado para as máquinas, você precisa entender o comportamento que você está descrevendo para a máquina. Comportamento Driven Design concentra em verificar o entendimento dos implementadores do Use Cases / Requisitos / O que quer e verifica a execução de cada recurso. BDD e TDD em geral serve o propósito importante de informar projeto ea segunda finalidade de verificar a regularidade da aplicação, especialmente quando se muda. BDD feito direito envolve biz e dev (e qa), enquanto Unit Testing (possivelmente incorretamente vista como TDD, em vez de um tipo de TDD) é normalmente feito no silo desenv.

Gostaria de acrescentar que os testes BDD servir como requisitos de vida.

Respondeu 28/05/2015 em 22:36
fonte usuário

votos
2

BDD é largamente TDD feito direito. No entanto, não há valor adicional que BDD oferece. Aqui está um link em que:

BDD é mais do que “direito TDD feito”

Respondeu 29/07/2010 em 11:25
fonte usuário

votos
2

Com o meu conhecimento mais recente em BDD quando comparado com TDD, BDD concentra-se em especificar o que vai acontecer a seguir, enquanto TDD centra-se na criação de um conjunto de condições e, em seguida, olhando para a saída.

Respondeu 25/05/2009 em 05:09
fonte usuário

votos
2

Parece-me que BDD é um escopo mais amplo. Quase implica TDD é usado, que BDD é a metodologia encompasing que reúne as informações e requisitos para a utilização, amongh outras coisas, as práticas de TDD para garantir uma resposta rápida.

Respondeu 05/08/2008 em 17:11
fonte usuário

votos
2

Behavior Driven Development parece se concentrar mais na interação e comunicação entre desenvolvedores e também entre desenvolvedores e testadores.

A Wikipedia artigo tem uma explicação:

Behavior Driven Development

Não praticar BDD me embora.

Respondeu 05/08/2008 em 17:06
fonte usuário

votos
1

Diferença entre o desenvolvimento orientado a testes (TDD) e desenvolvimento orientado a comportamento (BDD)

  • BDD se concentra no aspecto comportamental do sistema ao invés do
    aspecto implementação do sistema que TDD se concentra.

  • BDD dá uma compreensão mais clara sobre o que o sistema deve fazer
    a partir da perspectiva do desenvolvedor e o cliente. TDD única
    dá ao desenvolvedor uma compreensão de que o sistema deve fazer.

  • BDD permite que o desenvolvedor eo cliente para trabalhar em conjunto com a análise dos requisitos que está contido dentro do código-fonte do sistema.

Respondeu 09/06/2017 em 23:49
fonte usuário

votos
1

Aqui está a visão rápida:

  • TDD é apenas o processo de código de teste antes de escrever isso!

  • DDD é o processo de ser informado sobre o Domínio antes de cada ciclo de tocar código!

  • BDD é uma implementação de TDD que traz em alguns aspectos do DDD!

Espero que ajude!

Respondeu 18/01/2016 em 03:01
fonte usuário

votos
0

A escolha entre TDD e BDD é uma questão complicada. Depende se há uma estrutura de teste apropriado para o seu determinado idioma-alvo, o que seus colegas de trabalho é confortável com, e às vezes outros fatores.

Alguns argumentam que BDD é sempre melhor do que TDD porque tem a possibilidade de eliminar problemas que possam surgir ao usar TDD.

A chave para BDD é que ele pode evitar problemas; não é garantido para. Questões como a organização de código pobre, práticas de design ruim, etc. ainda vai persistir. Você só terá uma provável capa inferior de escrever testes ruins e, portanto, têm recursos mais robustos.

Respondeu 18/09/2016 em 09:59
fonte usuário

votos
0

Não há nenhuma diferença betwen TDD e BDD. exceto que você pode ler seus testes melhor, e você pode usá-los como requisitos. Se você escrever suas necessidades com as mesmas palavras que você escrever testes BDD então você pode vir frome seu cliente com alguns de seus testes definidos pronto para escrever código.

Respondeu 07/10/2014 em 09:52
fonte usuário

votos
-1

Este blog fornece um ponto de vista interessante sobre as diferenças entre TDD, BDD, e ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd-bdd-atdd/

Respondeu 20/05/2014 em 19:32
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more