Como usar testes de unidade ao usar o BDD?

Estou tentando entender o BDD. Eu li alguns artigos e, como eu entendi, o BDD é "o próximo passo" do TDD. Digo isso porque acho que ambos são muito semelhantes e, como pude ler neste artigo , o BDD nasceu como uma melhoria do TDD. Ótimo, eu realmente gosto da ideia.

Há um ponto prático que não entendi, pensou: há um arquivo .feature no qual o BA gravará todo o comportamento esperado no qual o sistema teria. Como bacharel, ele não tem idéia de como o sistema é construído, então escreveremos algo assim:

Cenário 1: a conta está sendo creditada

Dado que a conta está em crédito

E o cartão é válido

E o distribuidor contém dinheiro

Quando o cliente solicita dinheiro

Então garanta que a conta seja debitada E garanta que o dinheiro seja dispensado

E garanta que o cartão seja devolvido

Ok, isso é ótimo, mas há muitas partes do sistema que colaborarão para que isso aconteça (pense em Obj da conta, Obj do dispensador, Obj do cliente e assim por diante). Para mim, isso parece um teste de integração.

Eu gostaria de fazer testes de unidade. Como faço para testar o código que verifica se o distribuidor tem dinheiro? Ou que o dinheiro é dispensado? Ou que a conta é debitada quando necessário? Como posso misturar testes de unidade com testes "BA Created"?

O Desenvolvimento Orientado a Comportamento e o Desenvolvimento Orientado a Teste são complementares, mas não substituem um ao outro.

Como o aplicativo "se comporta" é descrito em Testes de aceitação, que de acordo com o BDD seriam os recursos e cenários escritos em Pepino.

Os detalhes detalhados de como cada componente pequeno funciona são descritos em Testes de unidade. Os resultados dos testes de unidade suportam os cenários que você escreve no pepino.

Imagine o processo de construção de um carro.

Primeiro, a equipe do produto apresenta suas idéias e, eventualmente, resume-as aos cenários de uso:

Scenario: Starting the car
    Given I am standing in front of the drivers door
    When I open the door
    Then the door should lift up DeLorean-style (yeah, baby!)
    When I get into the car
    And turn the key
    Then the engine roars to life

Sei que esse cenário parece um pouco tolo, mas é um requisito focado em produtos e usuários finais de nível muito alto. Apenas abrir a porta, girar a chave e dar partida no motor envolve MUITOS componentes diferentes trabalhando juntos. Este teste não é suficiente para garantir que o veículo funcione corretamente. Você precisa testar o motor de partida, a bateria, o alternador, a chave, o interruptor de ignição - e a lista continua - apenas para entrar no carro e ligá-lo. Cada um desses componentes precisa de seus próprios testes.

O cenário acima é um teste "Big Picture". Cada componente do veículo precisa de testes "Small Picture" para garantir que eles funcionem corretamente no conjunto.

Construir e testar software é o mesmo em muitos aspectos. Você projeta de cima para baixo e constrói de baixo para cima. Por que ter uma porta que se levanta se você nem consegue ligar o motor? Por que ter uma partida se você não tem bateria?

Sua equipe de produto apresentará os testes de aceitação e os detalhará em Pepino. Isso fornece o "Quadro geral". Agora cabe à equipe de engenharia projetar os componentes apropriados e como eles interagem e, em seguida, testar cada um separadamente - esses são seus testes de unidade.

Depois que os testes de unidade estiverem passando, comece a implementar os cenários de pepino. Após a aprovação, você entrega o que a equipe do produto solicitou.

Estou tentando entender o BDD. Eu li alguns artigos e, como eu entendi, o BDD é "o próximo passo" do TDD. Digo isso porque acho que ambos são muito semelhantes e, como pude ler neste artigo, o BDD nasceu como uma melhoria do TDD.

Na verdade, não, o BDD não é "o próximo passo" do TDD. Ele é TDD. Ou, mais precisamente, é uma reformulação do TDD.

Os criadores do BDD notaram que o principal obstáculo para entender que o TDD não é sobre teste, mas sobre especificação comportamental, era que toda a terminologia do TDD é sobre teste e não sobre especificação comportamental. É como tentar não pensar em um elefante rosa quando alguém lhe diz "tente não pensar em um elefante rosa", exceto com a complicação adicional de estar em uma sala cheia de elefantes rosa e um cara gritando constantemente "elefante rosa, rosa elefante, elefante rosa "no seu ouvido.

Então, eles reformularam o TDD em termos de especificação comportamental. "Testes" e "casos de teste" agora são "exemplos", "unidades" são "comportamentos", "asserções" são "expectativas" e assim por diante.

No entanto, a metodologia ainda é a mesma. Você começa com um teste de aceitação (quero dizer "recurso"), aumenta o zoom para um teste de unidade (quero dizer "exemplo"), diminui o zoom etc.

Eu gostaria de fazer testes de unidade. Como faço para testar o código que verifica se o distribuidor tem dinheiro? Ou que o dinheiro é dispensado? Ou que a conta é debitada quando necessário? Como posso misturar testes de unidade com testes "BA Created"?

Da mesma maneira que você faz no TDD. Você pode escrever seus recursos e seus exemplos em diferentes estruturas (por exemplo, Pepino e RSpec) ou até mesmo idiomas diferentes (por exemplo, escrever exemplos para um projeto C em C e recursos em FIT / Fitnesse), você pode usar uma única estrutura de recursos para ambos ( por exemplo, escrevendo exemplos e recursos no Cucumber) ou você pode usar uma estrutura de exemplos únicos para ambos (por exemplo, escrevendo ambos no RSpec). Você nem precisa usar uma estrutura.

Um exemplo de TDD feito corretamente (que é idêntico ao BDD) usando apenas uma única estrutura é a própria JUnit, que contém uma mistura de testes de unidade (exemplos) e testes de funcionalidade / integração (recursos), todos escritos na própria JUnit.

Eu acredito que Kent Beck chama isso de "zoom". Comece em alto nível, depois "amplie" os detalhes e depois volte novamente.

Isenção de responsabilidade: não sou especialista em BDD, mas tento dar a você meu ponto de vista sobre o artigo ao qual você vinculou.

TDD é uma técnica de implementação - você primeiro escreve um teste, depois implementa o método, executa seu teste, refatora e adiciona outros testes para o mesmo método ou para um novo método. O TDD, na verdade, não define nenhuma regra para escolher nomes de classes ou métodos, isso depende de você. O TDD também não informa "quando você terminar".

Portanto, sempre que você escreve um teste para um novo método, deve escolher um nome de método - e esse é o ponto em que o BDD entra. Escolhendo nomes de métodos usando os termos de negócios do cenário acima e escolhendo-os de uma maneira que descreva o comportamento da sua classe, você está fazendo BDD. Sempre que você se perguntar "eu tenho que adicionar mais testes", você pode ver os cenários fornecidos pelo seu BA e verificar se você implementou todas as partes necessárias completamente. Caso contrário, você precisará adicionar mais testes.

O autor do artigo também sugere usar um esquema de nomenclatura mais relacionado ao comportamento ao escolher os nomes dos seus testes; é por isso que ele substitui o JUnit por uma ferramenta que não depende de um esquema de nomenclatura no qual cada caso de teste deve começar. o nome "teste". Embora eu não conheça o JBehave, acho que essa é a principal diferença entre essa ferramenta e o Junit.

Além disso, os cenários do BDD também serão um modelo para os testes de integração - que você normalmente adicionará depois de detalhar os nomes dos métodos pelo TDD e depois de adicionar uma quantidade razoável de testes de unidade.

Portanto, a meu ver, o TDD é um instrumento que você pode usar como parte do BDD, e o BDD ajuda você a escrever os testes certos e dar-lhes nomes melhores.