DEV Community: Arthur Valentim Kasper

How to test external APIs with Webmock and VCR in RSpec

Arthur Valentim Kasper — Sat, 14 Oct 2023 14:08:53 +0000

Let’s talk about how we can test external APIs in our applications using Webmock and VCR, for this post, I‘ll use the RSpec suite. I’ll be very straightforward and minimalist in this explanation

💎 The examples will be done in a Rails app

🌐 Webmock

The webmock gem allows us to create stubs for HTTP requests, in other words, you can create fake returns for some internet service, without making the real request.

Setting

Adding to gem file

group :test do
  gem "webmock"
end

Inside the spec/scpec_helper.rb file, add the following require.

require 'webmock/rspec'

Run the bundle install to install the gem

bundle install

With this, the HTTP requests are disabled and the Webmock will always request the stubs of the responses, but making these stubs for all APIs can be tired, so for this, we will use VCR, which will do this “automatically” for us, so let’s see how we can do this.

📼 VCR

The VCR gem records the interaction of API calls for future usage, in other words, VCR creates a stub for us, making the real call only once and recording it in a file, to use for the next calls without making the real call again.

Setting

Adding to Gemfile

group :test do
  gem "vcr"
end

Adding the code block inside of spec/scpec_helper.rb :

VCR.configure do |config|
  config.cassette_library_dir = "spec/fixtures/cassettes"
  config.hook_into :webmock
  config.configure_rspec_metadata!
end

The property cassette_library_dir is about the path where the result of the APIs will be recorded, the hook_into is about Webmock (which we talked about in the previous topic) to disable the HTTP requests when necessary and the configure_rspec_metadata! allow us to use a property in our RSpec tests to keep them more simple using VCR, when we look at the code it will be more clear.

👨‍💻Testing

To show all the things I’ll make a simple get API call to JSON Placeholder in my test.

describe 'ServiceApi' do
  it 'get a post', :vcr do
    response = Net::HTTP.get('jsonplaceholder.typicode.com', '/posts/1')
    expect(response.code).to eq '200'
end

Note that in the it, I just add a :vcr argument, basicly with this I already informed the RSpec that the test will use the VCR, In case you had a multiple test, it’s possible add the :vcr argument directly in the describe.

When we ran the test, we have the following situation:

1 example, 0 failures

It passes as expected, note that a file was generated in the path that we set in cassette_library_dir property with the name of the test, it shows that the VCR made a request and recorded the response in an yml file, now, the next time that this test runs, the RSpec will get the data from this file instead made a real API call, in case you need regenerate the response, just delete the file and rerun the test.

Cool, right? This is a very simple way to work with external APIs in our tests and ensure that we will not have intermittent fails.

Com testar APIs externas com Webmock e VCR no RSpec

Arthur Valentim Kasper — Sat, 14 Oct 2023 12:00:19 +0000

Bora falar como podemos testar API externas a nossa aplicação em nossas aplicações utilizando Webmock e VCR, para este artigo estarei usando a suite de teste RSpec. Vou tentar ser bem minimalista e direto nas explicações*.*

💎 Os exemplos serão feitos em um app Rails

🌐 Webmock

O webmock é uma gem que nos permite criar stubs de chamadas HTTP, ou seja, ela permite criar retornos falsos para algum serviço de internet, mas sem fazer a chamada real.

Configurando

Adicionar no Gemfile

group :test do
  gem "webmock"
end

Dentro do seu arquivo spec/spec_helper adicionar o seguinte require

require 'webmock/rspec'

Rodar bundle install para instalar a gem

bundle install

Com isso as sua chamadas HTTP já ficam desabilitadas e o Webmock exigira que você realiza o stub dos retornos, mas fazer esses mocks/retornos para toda nova API que vamos testar pode ser tornar chato e cansativo, nesta parte que entra o VCR, que vai fazer isso “automagicamente” para nós, bora ver como isso pode ser feito.

📼 VCR

A gem VCR grava as iterações de suas chamadas para que o resultado dessas chamadas sejam utilizados no futuro, em outras palavras ela cria o stub para nós, realizando a chamada real uma única vez, após isso utiliza esse resultado para os testes.

Configurando

Adicionar no Gemfile

group :test do
  gem "vcr"
end

Adicionar esse trecho de código dentro de spec_helpers:

VCR.configure do |config|
  config.cassette_library_dir = "spec/fixtures/cassettes"
  config.hook_into :webmock
  config.configure_rspec_metadata!
end

A propriedade cassette_library_dir se refere ao local onde os retornos das APIs serão armazenados, já a hook_into nos diz que o webmock (que vimos no tópico anterior) é usado para desabilitar as chamadas http quando necessário e o configure_rspec_metadata! possibilita adicionar uma propriedade em nossos testes rspec para deixa-los menos verbosos ao usar o VCR, quando formos para o código isso ficará mais claro.

👨‍💻Testando

Para testar vou realizar uma simples chamada get para a API do JSON Placeholder em meu teste.

describe 'ServiceApi' do
  it 'get a post', :vcr do
    response = Net::HTTP.get('jsonplaceholder.typicode.com', '/posts/1')
    expect(response.code).to eq '200'
end

Perceba que no meu it, eu adicionei o argumento :vcr, basicamente com isso eu já informo para o RSpec que o teste usará o VCR, caso vc tenha multiplos teste, é possível adicionar o argumento diretamente no describe de seu teste.

Ao rodar o teste, temos a seguinte situação

1 example, 0 failures

Ele passou como esperado, peceba que foi gerado um arquivo no diretório que configuramos na propriedade cassette_library_dir do VCR com o nome do teste, isso demontra que o VCR fez a chamada e armazenou o conteúdo num arquivo yml, agora as próximas vezes que esse mesmo teste for executado, o RSpec vai consultar este arquivo (que pode ser chamado de cassete) e não realizará uma chamada real, caso você precise regerar o arquivo, basta excluílo e rodar o teste novamente.

Bacana né? Essa é uma forma bem simples de trabalharmos com APIs externas em nossos testes e garantirmos que não teremos falhas intermitentes.