Pepino vs RSpec (histórias sobre RSpec) [fechado]

Quando devo usar especificações para a aplicação Rails e quando Pepino (ex-rspec-stories)? Sei como funcionam e ativamente usam especificações, é claro. Mas ainda parece estranho usar o Pepino. Minha visão atual sobre isso é que é conveniente usar o Pepino quando você está implementando um aplicativo para o cliente e não entende como todo o sistema deve funcionar ainda.

Mas e se eu estiver fazendo meu próprio projeto? Na maior parte do tempo, sei como as partes do sistema interagem. Tudo o que preciso fazer é escrever vários testes de unidade. Quais são as possíveis situações em que eu precisaria do Pepino?

E, como uma segunda pergunta correspondente: eu tenho que escrever especificações se escrever histórias de pepino? Não seria um teste duplo da mesma coisa?

Se você ainda não o fez, pode conferir o excelente artigo de Dan North, O que há em uma história? como ponto de partida.

Temos dois usos principais para histórias de pepino. Primeiro, porque a forma da história é muito específica, ajuda a concentrar a articulação do proprietário do produto dos recursos que ele deseja criar. Esse é o uso "de token para uma conversa" de histórias e seria valioso se implementássemos ou não as histórias no código. Segundo, quando o processo está funcionando bem o suficiente para termos histórias completas antes de começarmos a escrever o artigo (mais um ideal pelo qual nos esforçamos do que uma realidade cotidiana), você tem seus critérios de aceitação claramente e sabe exatamente o que e como muito para construir.

Em nosso trabalho com o Rails, as histórias de pepino não substituem os testes de unidade rspec. Os dois vão de mãos dadas. Na prática, os testes de unidade tendem a impulsionar o desenvolvimento dos modelos e controladores, e as histórias tendem a impulsionar o desenvolvimento das visualizações (tendemos a não escrever rspec para nossas visualizações) e a fornecer um bom teste do aplicativo como um todo. perspectiva do usuário.

Se você trabalha sozinho, o aspecto da comunicação pode não ser tão interessante para você, mas o teste de integração que você obtém do Cucumber pode ser. Se você tirar proveito do webrat , escrever Pepino pode ser rápido e fácil para muitas das suas funcionalidades básicas.

Pense nisso como um ciclo:

Escreva o recurso Pepino e, ao desenvolver as peças para esse recurso, escreva especificações para completar os componentes individuais. Continue preenchendo as especificações até que você tenha escrito funcionalidade suficiente para o recurso passar e, em seguida, escreva o próximo recurso.

Minha opinião é que é uma má idéia usar o Pepino na maioria das situações devido aos custos de produtividade que sua sintaxe incorre em você. Eu escrevi extensivamente sobre o tópico em Por que se preocupar com testes de pepino?

Uma história de pepino é mais uma descrição do problema geral que sua aplicação está resolvendo, e não se bits individuais de código funcionam (por exemplo, testes de unidade).

Como Abie descreve, é quase uma lista de requisitos que o aplicativo deve atender e é muito útil para a comunicação com seu cliente, além de ser diretamente testável.

Atualmente, você pode usar o rspec com o Capybara e o Selenium Webdriver e evitar criar e manter todos os analisadores de histórias do Pepino. Aqui está o que eu recomendaria:

1. Escreva sua história
2. Usando o RSpec, eu criaria um teste de integração ex: spec / integrations / socks_rspec.rb
3. Então eu criaria um teste de integração que inclui uma nova descrição e bloqueia para cada cenário
4. Em seguida, implementaria a funcionalidade mínima necessária para obter o teste de integração e, ao voltar mais fundo (em controladores e modelos, etc.), TDD em controladores e modelos.
5. À medida que você volta, seu teste de integração deve passar e você pode continuar adicionando etapas ao teste de integração
6. repetir

Uma coisa a ser observada, no entanto, é que os testes de controlador e integração se sobrepõem, o que pode não ser necessário; portanto, você deve usar seu bom senso para não perder seu tempo.

Além disso, depois de encontrar o seu ritmo, você achará mais agradável desenvolver usando o BDD, até então não se sentirá culpado se não sentir que está fazendo o perfeito e não pensar demais. Você vai se sair bem!

Mas e se eu estiver fazendo meu próprio projeto? Na maior parte do tempo, sei como as partes do sistema interagem. Tudo o que preciso fazer é escrever vários testes de unidade. Quais são as possíveis situações em que eu precisaria do Pepino?

Você ainda precisa de pepino. Você precisa documentar como vê o sistema funcionando, e para garantir que não tenha quebrado a funcionalidade ao alterar as coisas.

Em outras palavras, você precisa de histórias de pepino pelas mesmas razões que de testes de unidade - elas apenas funcionam em um nível mais alto de abstração.