O que um request spec de fato é

A camada que o curso anterior deixou para depois

O curso logo antes deste, Testes de sistema: Capybara, passou sete aulas no type: :system: um navegador, JavaScript e a DSL do Capybara. Ele fechou nomeando a camada de baixo. É o spec/requests/ deste app, com dezenas de arquivos e algumas centenas de exemplos que já provam a correção do lado do servidor sem navegador. Este curso cobre essa camada a fundo.

A sintaxe: type: :request

Os request specs deste app abrem do mesmo jeito. Do spec/requests/auth_spec.rb:

require 'rails_helper'

RSpec.describe "Authentication", type: :request do
  let(:user) { create(:user) }

  describe "Sessions" do
    describe "GET /auth/sign-in" do
      it "renders the sign in page" do
        get auth_sign_in_path
        expect(response).to have_http_status(:success)
      end
    end
  end
end

O type: :request é a tag de metadados do RSpec, e o spec/rails_helper.rb deste app a descreve num comentário. "RSpec Rails uses metadata to mix in different behaviours to your tests, for example enabling you to call get and post in request specs." Declarar a tag é o que faz get, auth_sign_in_path e response existirem dentro do exemplo. O único arquivo em spec/requests/ sem a tag, client_ip_spec.rb, nem faz requisições: ele monta um ambiente Rack à mão e chama o ActionDispatch::RemoteIp diretamente.

Os helpers de verbo HTTP que os specs deste app chamam

Um grep em spec/requests/ acha o get com mais frequência, depois post, patch e delete. O put não aparece nenhuma vez: toda atualização nos specs deste app passa por patch, seguindo a convenção do Rails para atualizações parciais. Cada um é um método oferecido pelo maquinário do type: :request. Ele manda uma requisição no formato HTTP (verbo, caminho, parâmetros) para a aplicação inteira rodando e recebe uma resposta de volta.

Uma ida e volta completa, não um atalho

O get, post, patch ou delete de um request spec não chama uma action de controller direto, e não faz stub de nada por padrão. Ele entra pelo roteador do Rails e pela pilha de middleware: sessão, CSRF, a gem rack-attack deste app e tudo o mais que o config/application.rb liga. Depois chega à action do controller, roda os before_actions e o renderizador de view ou JSON, e volta como um objeto response. É a mesma ida e volta que um cliente HTTP faz, sem um socket TCP e sem navegador. É também a diferença para os system specs do curso anterior. Não há motor de renderização, sem JavaScript e sem DOM, só o caminho do servidor do começo ao fim.

O que este curso cobre

Sete aulas. Esta trata do type: :request e dos verbos que este app usa. A aula 2 trata das afirmações que os specs deste app fazem sobre uma resposta: have_http_status, response.body e o menos comum response.status. A aula 3 separa um request spec do system spec do curso anterior e do estilo mais antigo de controller spec. Ela mostra também por que os times do Rails e do RSpec hoje evitam esse último. A aula 4 cita o helper sign_in reutilizável deste app. A aula 5 percorre exemplos de CRUD e de JSON dos specs de admin e de execução deste app. A aula 6 trata de testar o que não deve acontecer: controle de acesso e caminhos de falha. A aula 7 junta tudo, com um pequeno desafio e uma indicação do próximo curso.