Faraday: Testseite für neue Dokumentation

Erstellt am 9. Juli 2019  ·  4Kommentare  ·  Quelle: lostisland/faraday

Basisinformation

  • Faraday-Version: Meister
  • Rubin-Version: 2.6.3

Fehlerbeschreibung

Es gibt keine Dokumentation zum Testen mit Faraday. Wo ich arbeite Ruby on Rails wurde eingeführt, weil es cool ist. Es wurde wenig daran gedacht, rote Fälle zu testen. Ich würde gerne eine Dokumentation beisteuern, um anderen zu helfen

Schritte zum Reproduzieren

  • besuche die Website.
  • Klicken Sie auf usage
  • Folgen Sie der Fußzeile der nächsten Links, bis Sie nicht weiter rechts gehen können (https://lostisland.github.io/faraday/usage/streaming)
  • Beachten Sie keine Tests in der Verwendung :scream_cat:

Hilfreichster Kommentar

Danke, dass Sie das ansprechen. Als Reaktion darauf habe ich eine PR mit Live-Test-/Einheits- und rspec-Beispielen für die Verwendung des Faraday-Testadapters veröffentlicht: Nr. 1000. Dies ist der empfohlene Weg, um Faraday zu testen, anstatt externe Doppelbibliotheken (rspec, mocha, webmock usw.) zu testen.

Alle 4 Kommentare

Danke, dass Sie das ansprechen. Als Reaktion darauf habe ich eine PR mit Live-Test-/Einheits- und rspec-Beispielen für die Verwendung des Faraday-Testadapters veröffentlicht: Nr. 1000. Dies ist der empfohlene Weg, um Faraday zu testen, anstatt externe Doppelbibliotheken (rspec, mocha, webmock usw.) zu testen.

Mir ist zu keinem Zeitpunkt aufgefallen, dass es Dinge wie Timeouts, Verbindungsfehler usw. testet. Ist das Thema verpönt oder nur so, wie PR #998 verwendet.

Ich nehme an, ich verstehe die Syntax nicht

Ich nehme an, ich verstehe die Syntax nicht

Oof, vielleicht sollte ich die Faraday-Testdokumente noch einmal durchsehen :/

Die Syntax in #1000 verwendet eine Faraday::Adapter::Test::Stubs Instanz, ein exklusives Stub-Objekt, um Faraday-Anforderungs-/Antwortzyklen zu testen. Sie können damit simulierte Antworten auf HTTP-Anfragen in einem bestimmten Test einrichten.

  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

Entschuldigung, ich habe Ihre Fragen offensichtlich nicht gründlich genug gelesen. Ich habe total übersehen, dass du gezielt Ausnahmen testen wolltest. Ein Test wie dieser funktioniert auch (den ich zu #1000 hinzufügen werde):

  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

Ich bevorzuge spezifische Testdoppelimplementierungen wie diese dem allgemeineren Mocking-Ansatz, da sie immer noch den gesamten Faraday-Anfrageworkflow durchlaufen. Wenn ein Entwickler sowieso RSpec-Mocks verwenden möchte, ist er mit der hervorragenden RSpec-Dokumentation besser bedient.

Geliefert mit #1000

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

jedeleh picture jedeleh  ·  3Kommentare

luizkowalski picture luizkowalski  ·  3Kommentare

mattmill30 picture mattmill30  ·  4Kommentare

subvertallchris picture subvertallchris  ·  5Kommentare

QuinnWilton picture QuinnWilton  ·  4Kommentare