O que uma spec de sistema de fato é

Uma lacuna que os request specs deste app não fecham

Este app tem dezenas de arquivos de request spec em spec/requests/, com algumas centenas de exemplos entre eles. O spec/requests/auth_spec.rb envia parâmetros de formulário para auth_sign_up_path e checa expect(response).to redirect_to(new_auth_two_factor_setup_path). Isso prova que o servidor aceitou o cadastro e mandou o redirect certo. Não prova nada sobre o que o navegador da pessoa fez no caminho. A lista de requisitos da senha ficou verde enquanto ela digitava? Um dropdown abriu quando ela clicou? Um request spec nunca roda uma linha de JavaScript e nunca toca um DOM. Um system spec é a resposta do Rails e do Capybara para essa lacuna.

A sintaxe: type: :system

RSpec.describe "Sign up", type: :system do
  it "shows a live password strength checklist as the user types" do
    visit auth_sign_up_path
    fill_in "password", with: "weak"
    expect(page).to have_content("At least 8 characters")
  end
end

O type: :system é a tag de metadados do RSpec, paralela ao type: :request que os request specs deste app já usam. Ela traz outro conjunto de ferramentas: o Capybara, conduzindo um navegador (ou um substituto rápido dentro do processo, assunto da aula 3) em vez de um cliente HTTP simples.

A DSL do Capybara, citada do README

O README do Capybara, que vem dentro da gem instalada, documenta o vocabulário em que um system spec é escrito. A navegação é o visit(path): "The visit method only takes a single parameter, the request method is always GET." A interação é click_link, click_button e click_on, que "clicks on either links or buttons". Formulários usam fill_in(label, with: 'value'), select(option, from: 'select box'), check, uncheck, choose e attach_file. As afirmações leem o page, não o response: have_content(text), have_css(selector), have_selector(selector) e have_current_path(path), mais as versões negativas (have_no_content, have_no_css e assim por diante). Todas vêm da API documentada do Capybara.

Logo de cara: a gem está aqui, e nada foi construído com ela ainda

grep -i capybara Gemfile                     # => gem "capybara"
grep -i selenium Gemfile Gemfile.lock        # => nenhum resultado
ls spec/system                               # => No such file or directory

Os três foram checados neste repositório. O capybara (3.40.0) está no Gemfile deste app, mas nada mais de que um spec que conduz um navegador precisa está. Não há a gem selenium-webdriver, da qual o driver padrão de system specs depende, e não existe diretório spec/system/. Uma gem no Gemfile e um spec que consegue conduzir um navegador são passos separados, e só o primeiro foi dado aqui. Esse é o ponto de partida deste curso. A próxima aula roda um spec neste app para mostrar como essa lacuna aparece hoje.

O que este curso cobre

Sete aulas. Esta trata do que é um system spec e da DSL do Capybara. A aula 2 mostra quanto do maquinário de system specs a gem rspec-rails instalada neste app já traz, lido do código-fonte e checado com um spec descartável rodado neste app. A aula 3 trata do rack_test, o driver padrão e rápido do Capybara, sem JavaScript. A aula 4 trata dos drivers que rodam JavaScript, as variantes do Selenium, a partir da documentação do Capybara. A aula 5 escolhe uma interação na página de cadastro deste app que só um system spec com JavaScript conseguiria verificar. A aula 6 faz o balanço do que os request specs deste app já provam sem navegador, e do que não conseguem. A aula 7 junta tudo e aponta para o próximo curso.