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
usage
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
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.).