Meilleures pratiques pour TDD BDD avec le code qui utilise des services externes/API

Question

J'utilise un joyau Twitter qui accède à Twitter et me permet de saisir des tweets, chronologie, etc. C'est vraiment bon, mais j'ai beaucoup de mon code qui utilise le ça retourne et je dois le tester. Les choses retournées par la gemme ne sont pas vraiment des ficelles simples, il y a des objets assez complexes (effrayants aussi) donc je suis parti me gratter la tête. Donc, fondamentalement, je suis à la recherche d'une réponse, livre, blog, projet open-source qui peut me montrer les droits et les torts de tester autour de services externes.

Les réponses qui ne sont pas centrées sur la langue ou ruby ​​/ rails centric seraient grandement appréciées.

Answer 1

Ce dont vous parlez, en réalité, ce sont deux types de tests que vous voudriez accomplir: les tests unitaires et les tests d'intégration.

Les tests unitaires testeront la validité des méthodes, indépendamment de toute donnée externe. Vous devriez regarder dans une sorte de cadre moqueur, basé sur la langue que vous utilisez. Vous cherchez essentiellement à dire, avec les tests, quelque chose d'équivalent à "si ces hypothèses sont qualifiées, alors ce test devrait produire ..." Le cadre de création définira vos hypothèses, en termes de dire que certaines classes/objets sont définis dans d'une manière particulière et peut être supposé être valide. Ce sont les tests qui ne reposent pas sur le fait que Twitter soit vivant, ou que la troisième partie de la bibliothèque/API soit réactive.

Les tests d'intégration effectuent des tests en direct par rapport à la source de données, en consommant la bibliothèque/API pour effectuer des actions réelles. Lorsque cela devient délicat, puisque vous utilisez un service tiers, vous écrivez au service (c'est-à-dire si vous créez de nouveaux Tweets). Si vous êtes, vous pouvez toujours créer un compte sur Twitter qui pourrait être utilisé uniquement pour les opérations d'écriture. Généralement, si vous étiez en train de tester une base de données locale, par exemple, vous pourriez alors utiliser des transactions pour tester des opérations similaires; reculer les transactions au lieu de les commettre.

Voici quelques non linguistiques spécifiques, des définitions de haut niveau:

• Wikipedia (Software Testing)
• Wikipedia (Mock Object)

Je suis d'une pile .NET, donc je ne vais pas faire semblant pour en savoir beaucoup sur Ruby. Une recherche rapide sur Google, cependant, a révélé, ce qui suit:

• Mocha (Ruby Mocking Framework)

Answer 2

Vous pouvez facilement bouchonner à la couche HTTP en utilisant quelque chose comme wiremock http://wiremock.org/ Je l'ai utilisé cela sur quelques projets maintenant et il est assez puissant et rapide. Cela permettra d'éliminer tout le code de mise en place du code basé sur la moquerie - il suffit de lancer le pot avec les cartographies connexes et bob votre oncle.