Faraday: Page de test pour la nouvelle documentation

Créé le 9 juil. 2019  ·  4Commentaires  ·  Source: lostisland/faraday

Informations de base

  • Version Faraday : maître
  • Version Rubis : 2.6.3

Description du problème

Il n'y a pas de documentation sur les tests avec Faraday. Là où je travaille, Ruby on Rails a été introduit parce que c'est cool. On a peu pensé au test des cas rouges. J'aimerais contribuer de la documentation pour aider les autres

Étapes à reproduire

  • visiter le site Web.
  • Cliquez sur usage
  • suivez les liens suivants du pied de page jusqu'à ce que vous ne puissiez plus continuer à droite (https://lostisland.github.io/faraday/usage/streaming)
  • remarquez aucun test d'utilisation :scream_cat:

Commentaire le plus utile

Merci de le mentionner. En réponse, j'ai posté un PR pour inclure des exemples de test/unité en direct et rspec d'utilisation de l'adaptateur de test Faraday : #1000. C'est la méthode recommandée pour tester Faraday, au lieu de tester des bibliothèques doubles externes (rspec, mocha, webmock, etc.).

Tous les 4 commentaires

Merci de le mentionner. En réponse, j'ai posté un PR pour inclure des exemples de test/unité en direct et rspec d'utilisation de l'adaptateur de test Faraday : #1000. C'est la méthode recommandée pour tester Faraday, au lieu de tester des bibliothèques doubles externes (rspec, mocha, webmock, etc.).

J'ai remarqué qu'à aucun moment il ne teste des choses telles que les délais d'attente, les erreurs de connexion, etc. Le sujet est-il mal vu, ou simplement la façon dont PR #998 utilise.

Je suppose que je ne comprends pas la syntaxe

Je suppose que je ne comprends pas la syntaxe

Oof, peut-être que je devrais revoir la doc de test de Faraday :/

La syntaxe dans #1000 utilise une instance Faraday::Adapter::Test::Stubs , un objet stub exclusif pour tester les cycles de requête/réponse de Faraday. Vous pouvez l'utiliser pour configurer des réponses fictives aux requêtes http dans un test spécifique.

  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

Je m'excuse, je n'ai visiblement pas assez lu vos problèmes. J'ai totalement raté que vous vouliez spécifiquement tester les exceptions. Un test comme celui-ci fonctionne aussi (que j'ajouterai au #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

Je préfère les doubles implémentations de test spécifiques comme celle-ci à l'approche de moquerie plus généralisée, car elles passent toujours par l'ensemble du flux de travail de demande Faraday. Si un développeur souhaite de toute façon utiliser des simulations RSpec, il sera mieux servi avec l'excellente documentation RSpec.

Livré avec #1000

Cette page vous a été utile?
0 / 5 - 0 notes