Faraday: Página de teste para nova documentação

Obrigado por trazer isso. Em resposta, publiquei um PR para incluir exemplos de teste / unidade ao vivo e rspec do uso do adaptador de teste Faraday: # 1000. Esta é a maneira recomendada de testar o Faraday, em vez de testar bibliotecas duplas externas (rspec, mocha, webmock, etc).

Percebi que em nenhum momento ele está testando coisas como tempos limite, erros de conexão, etc. O assunto é desaprovado ou apenas a forma como o PR # 998 usa.

Acho que não entendi a sintaxe

Acho que não entendi a sintaxe

Ufa, talvez eu deva revisitar os documentos de teste de Faraday novamente: /

A sintaxe em # 1000 usa uma instância Faraday::Adapter::Test::Stubs , um objeto stub exclusivo para testar ciclos de solicitação / resposta de faraday. Você pode usá-lo para configurar respostas simuladas para solicitações http em um teste específico.

  it 'parses name' do
    # this block yields a rack response: an array with:
    # response status, http header hash, and response body
    stubs.get('/ebi') do |env|
      [
        200,
        { 'Content-Type': 'application/javascript' },
        '{"name": "shrimp"}'
      ]
    end

    expect(client.sushi('ebi')).to eq('shrimp')
    stubs.verify_stubbed_calls
end

Peço desculpas, obviamente não li seus problemas o suficiente. Eu perdi totalmente que você queria testar exceções especificamente. Um teste como este também funciona (que adicionarei a # 1000):

  it 'handles exception' do
    stubs.get('/ebi') do
      raise Faraday::ConnectionFailed, nil
    end

    expect { client.sushi('ebi') }.to raise_error(Faraday::ConnectionFailed)
    stubs.verify_stubbed_calls
  end

Eu prefiro implementações de teste duplo específicas como esta à abordagem de mocking mais generalizada, já que eles ainda passam por todo o fluxo de trabalho de solicitação de Faraday. Se um desenvolvedor quiser usar mocks RSpec de qualquer maneira, ele será mais bem servido com a excelente documentação RSpec.

Entregue com # 1000