Relação entre BDD e TDD

Qual é a relação do BDD e TDD?

Pelo que entendi, o BDD adiciona duas coisas principais ao TDD: nomeação de testes (garantir / deveria) e testes de aceitação. Devo seguir o TDD durante o desenvolvimento pelo BDD? Se sim, meus testes de unidade TDD devem ser nomeados no mesmo estilo de garantir / deve?

O BDD adiciona um ciclo ao redor do ciclo TDD.

Então você começa com um comportamento e deixa isso conduzir seus testes, depois deixa os testes conduzirem o desenvolvimento. Idealmente, o BDD é conduzido por algum tipo de teste de aceitação, mas isso não é 100% necessário. Contanto que você tenha o comportamento esperado definido, você estará bem.

Então, digamos que você esteja escrevendo uma Página de Login.

Comece com o caminho feliz:

Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page

Essa sintaxe do tipo Dado-e-Quando-E-E-E é comum no desenvolvimento orientado pelo comportamento. Uma das vantagens disso é que ele pode ser lido (e, com treinamento, escrito) por não desenvolvedores - ou seja, seus stakeholders podem visualizar a lista de comportamentos que você definiu para a conclusão bem-sucedida de uma tarefa e ver se ela corresponde às expectativas muito antes de você lançar um produto incompleto.

Existe uma linguagem de script, conhecida como Gherkin, que se parece muito com a acima e permite que você escreva código de teste por trás das cláusulas desses comportamentos. Você deve procurar um tradutor baseado em Gherkin para sua estrutura de desenvolvimento usual. Isso está fora do escopo desta resposta.

Enfim, de volta ao comportamento. Seu aplicativo atual ainda não faz isso (se o faz, por que alguém está solicitando uma alteração?), Então você está reprovando neste teste, esteja usando um corredor de teste ou simplesmente testando manualmente.

Então agora é hora de mudar para o ciclo TDD para fornecer essa funcionalidade.

Esteja você escrevendo BDD ou não, seus testes deverão ter o nome de uma sintaxe comum. Uma das mais comuns é a sintaxe "should" que você descreveu.

Escreva um teste: ShouldAcceptValidDetails. Passe pelo ciclo Vermelho-Verde-Refatorador até ficar satisfeito. Agora passamos no teste de comportamento? Caso contrário, escreva outro teste: ShouldRedirectToUserDefaultPage. Refator vermelho-verde até você ficar feliz. Lave, enxágue, repita até cumprir os critérios estabelecidos no comportamento.

E então passamos para o próximo comportamento.

Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"

Agora você não deveria ter antecipado isso para passar seu comportamento anterior. Você deve falhar neste teste neste momento. Então volte ao seu ciclo TDD.

E assim por diante até você ter sua página.

Recomendo o The Rspec Book para aprender mais sobre o BDD e o TDD, mesmo que você não seja um desenvolvedor Ruby.

Minha compreensão disso:

• O BDD começou como uma rebranding do TDD para tornar o foco no comportamento mais claro.
• Oferece suporte mais formal (DSL e ferramentas) para um foco no comportamento e nas especificações executáveis.
• O BDD agora pode ser visto como um superconjunto do TDD. Com o passar do tempo, cresceu para abranger mais aspectos, mas o lado do processo de desenvolvimento é uma parte essencial.

Então, para abordar o TDD feito parte correta do BDD. O BDD começou como uma mudança na linguagem do TDD para tornar clara a intenção do processo. O artigo introdutório de Dan North no BDD explica por que o foco na palavra comportamento, em vez de teste, é útil - ajuda a confirmar que você não está apenas criando o software certo, mas também o software certo. Isso sempre fez parte de uma boa abordagem de TDD, mas Dan a codificou um pouco no BDD.

O que eu acho que o BDD torna um pouco mais explícito que o TDD, ou pelo menos formaliza e fornece suporte para ferramentas, é essa abordagem de dois ciclos / loop duplo / zoom in, zoom out / outside-in. Primeiro, você descreve o comportamento esperado do recurso (o loop externo) e, em seguida, aumenta o zoom no loop interno para lidar com as especificações de baixo nível.

De http://www.metesreau.com/ncraft-workshop/

O Gherkin, em conjunto com ferramentas como Cucumber e SpecFlow, fornece uma maneira de escrever essas especificações de alto nível e, em seguida, vinculá-las ao código que executa o código do aplicativo. Eu diria que é aqui que o BDD pode 'parecer' diferente do TDD, mas ele realmente ainda está fazendo a mesma coisa, apenas com algum suporte adicional à ferramenta e uma DSL. Um pouco mais próximo do TDD 'tradicional', está usando ferramentas como rspec, nspec, spock. Eles se parecem um pouco com o mesmo processo que você faria no TDD 'tradicional', mas com uma linguagem mais focada no comportamento.

No BDD in Action, de John Ferguson Smart (altamente recomendado), ele defende uma abordagem de loop duplo, começando com algo como jBehave nas especificações executáveis ​​de nível externo e, em seguida, adotando uma ferramenta como Spock para as especificações de baixo nível.

O BDD aproxima o conceito de teste das partes interessadas da empresa. O Gherkin foi projetado para ser legível para os negócios, e a idéia de 'documentação viva', ou seja, relatórios de progresso produzidos automaticamente a partir de suas especificações executáveis, é sobre dar feedback às partes interessadas.

Outra parte do BDD agora, que é onde ele genuinamente se torna algo que incorpora o TDD como parte de um processo maior, são os bits e partes de elicitação de requisitos. Ideias como Injeção de Recursos, Mapeamento de Impacto e Opções Reais fazem parte desse lado.

Para a resposta canônica, talvez seja melhor ir para Dan North novamente . Se sua equipe é formada por todos os desenvolvedores, então BDD = TDD. Se sua equipe envolve uma série de partes interessadas, o BDD está mais próximo do XP, com o TDD sendo uma parte dele.

Qual é a relação do BDD e TDD?

Eles são a mesma coisa.

Pelo que entendi, o BDD adiciona duas coisas principais ao TDD: nomeação de testes (garantir / deve)

Isso não é realmente algo que o BDD "acrescenta". É apenas uma convenção diferente que visa facilitar o ensino e a compreensão do TDD.

As pessoas que criaram o BDD estavam ensinando TDD e perceberam que a coisa mais difícil de entender era que o TDD não tem absolutamente nada a ver com o teste. Depois que os alunos superaram esse obstáculo, ficou muito mais fácil para eles. Porém, é muito difícil se divorciar de pensar em testar , quando a palavra "teste" (ou terminologia relacionada como "afirmar") aparece praticamente em todos os lugares . Então, eles trocaram algumas palavras.

Mas são apenas as palavras! Não há diferença real entre TDD e BDD.

e testes de aceitação.

Os testes de aceitação fazem parte do TDD tão importante quanto o do BDD. Novamente: não há diferença entre TDD e BDD: TDD feito corretamente é BDD, BDD é feito corretamente.