Usando RSpec e Capybara para testar uma feature numa aplicação Rails
Depois de criar nossa aplicação Rails, nós instalamos RSpec e Capybara, e até já escrevemos um teste bem simples para testar a nossa home. Agora vamos criar um teste de feature, ainda simples, mas com algumas novidades. Vamos testar a feature de edição da classe Item, que foi criada no post anterior.
Vamos lá?
1 - Crie o arquivo 'user_edits_item_spec.rb' no diretório spec/features
Como nosso outro teste, este é um teste de feature, então ele deve ser criado dentro do diretório features no diretório spec.
O nome segue algumas convenções no sentido de ser descritivo da ação que será testada. O mais importante no nome é o final _spec.rb, pois é este sufixo que faz o Rails e o RSpec saberem que se trata de um arquivo que tem um teste a ser rodado.
2 - Inicie o arquivo com um require do rails_helper
Esta linha é necessária para que as configurações pré estabelecidas sejam carregadas.
# spec/features/user_edits_item_spec.rb require 'rails_helper'
3 - Acrescente o bloco para a feature
Eu geralmente nomeio o arquivo de teste e a feature dentro do arquivo da mesma forma. Aprendi assim quando aprendi o B+A=BA do Rails e adoro o quanto isso facilita na hora de encontrar testes que precisam ser analisados e/ou atualizados numa alteração qualquer.
# spec/features/user_edits_item_spec.rb require 'rails_helper' feature 'user edits item' do end
4 - Acrescente o bloco do cenário
Por padrão, o primeiro cenário de um teste de feature é aquele onde tudo está perfeito e dá certo. O nosso ideal ao criar a feature.
# spec/features/user_edits_item_spec.rb require 'rails_helper' feature 'user edits item' do scenario 'sucessfully' do end end
Agora a coisa vai ficar legal! :-) Antes de proceder, precisamos lembrar que um bom teste de feature tem 3 partes:
- Configuração: Preparamos o ambiente e a situação
- Ação: Fazemos o que queremos testar
- Expectativa: Esperamos um determinado resultado
5 - Monte a configuração da situação
No nosso caso, queremos testar a edição de um item. Para que o item seja editado, ele precisa primeiramente existir, então vamos criar um item qualquer.
# spec/features/user_edits_item_spec.rb require 'rails_helper' feature 'user edits item' do scenario 'sucessfully' do Item.create(name: 'example', price: 1) end end
6 - Descreva as ações que devem ser testadas
A ação de editar um item, começa quando o usuário clica num link ou botão de editar, certo? Onde o usuário está neste momento? É lá que precisamos começar.
No nosso caso, o usuário estaria na index dos itens, então vamos começar com ele visitando esta página. Uma vez que ele esteja lá, queremos que ele clique em editar, altere algumas informações, e salve estas alterações.
No ambiente do RSpec com o Capybara, estes passos são simulados assim:
visit items_path click_on 'Edit' fill_in 'Name', with: 'changed' fill_in 'Price', with: 2 click_on 'Update Item'
São várias linhas, mas graças as magias do RSpec e do Capybara, são bem simples e descritiva do que está acontecendo.
7 - Declare o resultado esperado
A terceira parte, conforme vimos a pouco, é a expectativa. Precisamos declarar o que queremos que aconteça quando as ações do passo acima forem executadas.
Neste caso queremos que a aplicação nos diga se deu tudo certo e nos mostre o item com seus dados atualizados. Fazemos isso da seguinte forma:
expect(page).to have_content 'Item was successfully updated.' expect(page).to have_content 'Name: changed' expect(page).to have_content 'Price: 2'
Pronto!
Nosso arquivo completo ficou assim:
# spec/features/user_edits_item_spec.rb require 'rails_helper' feature 'user edits item' do scenario 'sucessfully' do Item.create(name: 'example', price: 1) visit items_path click_on 'Edit' fill_in 'Name', with: 'changed' fill_in 'Price', with: 2 click_on 'Update Item' expect(page).to have_content 'Item was successfully updated.' expect(page).to have_content 'Name: changed' expect(page).to have_content 'Price: 2' end end
Vamos rodar o rspec no nosso terminal para ver o que acontece?
Perfeito! Agora temos 2* testes e os dois estão passando**! :-)
* Se você está seguindo a série sampope como um tutorial e fazendo cada passo, possivelmente terá mais de 2 testes, porque no sampope 8 usamos Scaffold, que geralmente cria vários arquivos de teste automaticamente.
** Geralmente um teste que acaba de ser criado não passa, porque a prática correta é primeiro escrever o teste para depois desenvolver a feature. No nosso caso, já tínhamos feito a feature no post anterior. Este post é apenas para mostrar como escrever estes tipos de teste, por isso ele foi criado já passando.

Nenhum comentário:
Postar um comentário