O RSpec e o Pepino realmente valem a pena?

Eu sei que a maioria dos programadores de RoR está testando viciados e compreendo as vantagens de um grande conjunto de testes, mas quando começo a testar, nunca recebo um conjunto tão grande e sempre me pergunto "Estou testando da maneira certa? Existem realmente eficientes?". Costumo lidar com testes de integração testando apenas o modo como o aplicativo se comporta.

Primeiro, vale a pena testar? Quero dizer, o tempo gasto em escrever testes realmente vale a pena?

Então, eu uso o RSpec, descobri recentemente o Pepino, usei por um tempo, mas não sei se escrever todas essas etapas realmente vale a pena. Sei que posso reutilizar as etapas, mas nunca sei se essas etapas são muito completas ou não: por exemplo, estou usando um, Given I am logged in as (.+)mas não sei se devo dizer em sua definição, Given there's a user called $1pois ele pode duplicar o usuário, se alguma vez foi criado. mas isso não vale a pena sempre dar um passo antes Given I am logged in as (.+). É bastante código que talvez raramente seja útil. Eu acho que não há novos bugs nas peças testadas todos os dias ... Então o Cucumber realmente vale a pena em comparação com o RSpec?

Meu 'ah-ha!' momentos sobre os testes em Ruby e Rails vieram quando eu realmente me sentei e li os recursos definitivos sobre o assunto, os livros Rspec e Cucumber . Eu compartilhei seu desdém inicial por Pepino, mas então percebi que estava olhando a foto pelo ângulo errado.

Basicamente, o Pepino é sobre BDD (desenvolvimento orientado a comportamento) - você usa o Pepino para planejar seus recursos, no que trabalhará a seguir. Hmm, em seguida, você deseja que os usuários possam promover postagens em um fórum ou algo assim (para roubar um exemplo;)) Então você escreve algo simples.

Given I am logged in
And I can see the post "BDD is awesome"
When I vote the post up
Then the post should have one more vote
And the page should show a message thanking me for my vote.

Observe que não há referências a qualquer código relacionado lá. Isso vem em seus passos. Quando você refatorar seu código, talvez seja necessário alterar suas definições de etapa, mas o comportamento (seu recurso) nunca precisará ser alterado.

Agora, toda vez que você executar o recurso Pepino, você será orientado sobre como testar o recurso usando TDD (desenvolvimento orientado a teste). Isso é feito em um nível inferior usando o RSpec.

Primeira execução - minha definição da primeira etapa é indefinida. Copie o bloco para defini-lo em, por exemplo, user_steps.rb ou mesmo session_steps.rb, porque está relacionado aos usuários e suas sessões. Agora, como você define que um usuário está logado? Você pode levá-los através do processo de login.

Given /^I am logged in$/ do
  visit login_path
  fill_in :name, :with => 'Joe'
  fill_in :password, :with => 'Password'
  click_button 'submit'
end

Deveria ser todo feliz. Segundo passo.

Given /^I can see the post "(.+)"$/ do |name|
  visit post_path(Post.find_by_name(name))
end

Mais uma vez bem fácil. Observe que, se refizermos totalmente nosso processo de login ou como nossas postagens são definidas e exibidas, não precisamos alterar o comportamento. Terceiro passo.

When /^I vote the post up$/ do
  pending 
end 

Aqui é onde você começa a falar sobre novas funcionalidades, mas ainda não sabe como isso vai funcionar. Como você vota uma postagem? Você pode clicar em uma imagem de +1 ou algo assim, que faz uma postagem do ajax em um controlador, que retorna JSON ou algo parecido. Então agora você pode passar para o teste Rspec puro.

• Teste sua visualização para garantir que a imagem +1 seja exibida,
• Teste o seu controlador se ele se comporta corretamente quando recebe uma solicitação ajax do formato correto (os caminhos feliz e infeliz - e se um ID de postagem inválido for recebido? O que acontece se o usuário tiver esgotado os 25 upvotes em um dia? Aumenta o número de votos corretamente?)
• Teste seu javascript se ele responde corretamente quando recebe um blob de JSON no formato correto (atualiza a imagem +1 para mostrar que foi usada? (Pensando no Google+ aqui ...) Mostra a mensagem de agradecimento? Etc. )

Tudo isso não afeta o comportamento - mas quando você terminar de lidar com os testes de nível inferior, será trivial preencher a definição da etapa de como votar em uma postagem. Pode ser tão simples quanto click_link '+1'. E o restante das etapas está testando resultados, o que novamente deve ser simples de fazer. E quando terminar, você sabe que seu recurso está completo e concluído. Se o comportamento necessário mudar, você poderá ajustar seu recurso, ou o código de implementação em perfeita segurança.

Espero que isto faça sentido. Está tudo errado, mas acho que demonstra a diferença entre o BDD e o TDD, e por que o Cucumber e o RSpec atendem a diferentes necessidades.

Testar, na minha opinião, é uma arte. Fazer TDD (usando RSpec ou qualquer outra estrutura) inicialmente parece que você está "desperdiçando seu tempo". Isso é compreensível porque você não está escrevendo nenhum código de produção.

No entanto, você começa a ver os benefícios do TDD quando precisa aprimorar sua base de código e garantir que tudo o mais ainda funcione. O TDD ajuda a detectar erros de regressão o mais cedo possível. Fazer isso me salvou dias de trabalho, porque eu tinha focado testes que apontavam meus erros.

Além disso, a realização de testes pode ser benéfica para as revisões de código, porque o revisor pode ver quais cenários você está testando e como seu código deve ser usado.

Depois de entrar no balanço do TDD, fazer qualquer outra coisa parece errado.

Minha opinião é que você está bem na frente do pepino. Escrever todas essas etapas é muito problemático, e os benefícios não justificam a dor. Escrevi extensivamente sobre as seis desvantagens do uso do pepino aqui: Por que se preocupar com o teste do pepino?

Testes de unidade e testes regulares de integração, feitos com Rspec ou Test :: Unit, fazem muito sentido, mas felizmente são muito mais rápidos de escrever do que os testes de pepino. Por um lado, você pode usar Ruby puro em vez de ter que combater a sintaxe prolixo e estranha de Gherkin.

O que eu pessoalmente acredito é isso RSpec testing is a definite must. Digamos, por exemplo, que você queira escrever um novo recurso e que também tenha referência a algum outro recurso, e esse recurso possa ser referenciado com outros módulos ou métodos. Então, como você pode ter certeza de que o que está escrevendo não está quebrando nenhuma outra parte do aplicativo?

Suponha que você tenha um aplicativo grande e que tenha codificado algo trivial em comparação com o aplicativo geral, testará novamente o aplicativo inteiro clicando em todos os links do aplicativo para garantir que funcione toda vez que alterar uma única linha de código?

No entanto, acredito que o teste de pepino não é obrigatório. Eu acho que o teste de integração usando o próprio RSpec faz mais sentido até e a menos que você precise fazer os testes verificados pelo seu cliente. Que na minha experiência é raro. Se sua equipe é formada inteiramente por desenvolvedores, acho que você deve substituir as etapas de pepino para o teste de recursos do RSpec. E acho que após o DSpec RSpec 3, os testes são praticamente legíveis.

Ex:

Definição de etapa de pepino:

Given /^I am logged in$/ do
  visit login_path
  fill_in :name, :with => 'Joe'
  fill_in :password, :with => 'Password'
  click_button 'submit'
end

Teste de recursos do RSpec:

feature 'Given the user is logged in' do
      visit login_path
      fill_in :name, :with => 'Joe'
      fill_in :password, :with => 'Password'
      click_link_or_button 'submit'
end

Acho que, em vez de ter recursos de pepino, os recursos do RSpec fazem a mesma coisa sem a dor de cabeça extra de escrever outras definições de etapas.

Fora isso, também é puramente sua preferência.

Espero que isso ajude você a entender um pouco.

Na minha opinião, a primeira coisa é diferenciar práticas e estruturas concretas. Pepino não é BDD, RSpec não é TDD.

Se você quiser testar o RSpec do seu sistema, é uma boa ferramenta, você pode fazer TDD ou BDD com o RSpec, na verdade, TDD e BDD são a mesma coisa. Alguém diz "BDD, seu TDD está certo" e eu concordo totalmente com isso. O BDD é principalmente sobre testar recursos / comportamentos em vez de testar métodos / classes. De fato, o TDD que Kent Beck descreve sobre seus recursos, mas o BDD ajuda muitas pessoas a entender essa diferença importante e é uma grande contribuição de Dan North para a comunidade de desenvolvimento.

Use o Pepino se achar que precisa de uma ferramenta melhor para se comunicar com pessoas de negócios, por exemplo, se o pepino permitir que as pessoas de negócios ou o proprietário do produto ajudem a equipe a escrever ou revisar cenários. Outras pessoas gostam de pepino porque esses cenários são realmente uma boa documentação ao vivo de um sistema, se você sentir que precisa desse tipo de documentação, tente pepino.

Em suma:

• Se você quer fazer o TDD / BDD você mesmo ou sua equipe -> tente o RSpec
• Se você deseja uma maneira melhor de se comunicar com os negócios com Histórias e Cenários do Usuário -> tente pepino
• Se você quiser documentação ao vivo dos recursos do seu sistema -> tente pepino.

É claro que os dois últimos têm um alto custo associado, você precisa avaliar se realmente precisa disso e vale o esforço, esse curso depende totalmente do seu projeto e do seu ambiente, e a decisão depende de você.

Mas lembre-se sempre de que o RSpec e o Pepino são apenas ferramentas, e as ferramentas resolvem problemas concretos, qual o problema que você deseja resolver ?, faça a si mesmo esta pergunta e você provavelmente estará em uma posição melhor para selecionar a ferramenta certa. Seja um programador melhor, é sobre tomar essas decisões e não sobre o uso da estrutura / ferramenta / biblioteca / tecnologia X ou Y.