J'apprends à la fois la plaisanterie et le cyprès en même temps. Je sais qu'ils ne sont pas des concurrents directs parce que Cypress se concentre sur E2E et plaisante sur les tests unitaires. Pour l'instant, j'ai mis en œuvre dans mon projet Jest et Cypress avec peu de tests.
Mais en fait, la plupart des choses que je peux tester à la fois dans Cypress et en plaisantant, et souvent j'ai du mal à décider avec ce qui rédige mon test. Il est également plus difficile à maintenir par rapport à la bibliothèque de tests unique.
Je me demande - à quelle fréquence le cyprès (ou alternative) et la plaisanterie (ou alternative) sont-ils utilisés ensemble? Est-ce vraiment standard et une bonne pratique d'utiliser les deux? Ou la plupart des développeurs / équipes s'en tient à une solution unique et c'est bien?
Mettre à jour l'édition : Cela a été longtemps depuis que cette question a été posée. J'ai obtenu un compromis qui a également été suggéré dans commentaire. Au lieu de l'utilisation uniquement de Cypress ou Cypress + Jest, j'utilise Cypress + New Cypress Component Testing (donc pas de plaisanterie). Merci à cela, j'ai la même bibliothèque et les affirmations (plus facile à gérer), mais je peux tester à la fois E2E et Composants.
3 Réponses :
Réponses courtes: il est très courant d'utiliser la plaisanterie et le cyprès dans la même base de code.
Unité, intégration ou tests E2E
Avec des bibliothèques de composants comme Vue et React, la ligne entre l'intégration et les tests unitaires peut devenir un peu floue. Nous pouvons même utiliser les mêmes outils (plaisanterie et cyprès) pour les deux cas, ce qui rend les choses encore plus déroutantes. Je vous recommande de viser à tester les "histoires d'utilisateurs" ou, en d'autres termes, assurez-vous que les utilisateurs peuvent toujours effectuer des actions clés. Par exemple:
Certains de ces tests impliqueront un composant, d'autres en impliqueront deux et certains nécessiteront l'ensemble de l'application. Je préfère écrire des tests plus petits (unité et intégration) en utilisant la plaisanterie et Test Library En raison de la boucle de rétroaction rapide. Je peux développer et exécuter mes tests, presque, en même temps.
Finalement, vous rencontrerez des cas qui impliquent autant de pièces mobiles (composants) que l'utilisation de la plaisanterie n'est pas une option. C'est là que le cyprès brille, c'est idéal pour tester vos flux de travail de bout en bout.
Avec la nouvelle bibliothèque de tests de composants, je peux voir Cypress remplacer également la plaisanterie pour tester vos composants. Sur la base d'une vidéo que j'ai vue où Lachlan Miller jouait avec, cela semblait assez vif.
J'utilise Cypress pour les tests E2E et les tests de composants. Je teste les comportements de ces types avec du cyprès. Avec une plaisanterie, je fais des tests unitaires. Avec Jest-je teste Logic / Business-Logic dans le frontend.
Il s'agit d'une vieille question, mais je voulais fournir une clarté supplémentaire pour expliquer pourquoi vous utiliseriez à la fois Cypress et plaisanterie. J'ai utilisé les deux sur plusieurs projets. Ils répondent à chacun des préoccupations de tests distinctes:
pour exécuter des tests unitaires. Les tests unitaires confirment logique métier ou tout simplement qui garantissent que vos méthodes renvoient la valeur attendue pour de nombreux cas différents. Généralement, ces tests sont destinés aux méthodes de services, mais sans s'y limiter.
pour exécuter des tests de bout en bout ou fonctionnels. Cypress est pour tester l'interface utilisateur spécifiquement en interagissant avec lui et en faisant des affirmations dessus. Les appels au backend sont généralement tronqués, ce qui signifie que vous contrôlez la réponse dans le test, car Cypress n'est pas pour tester le backend.
Ensemble, Cypress et la plaisanterie fournissent une solution de test complète pour le frontend.
Ils sont orthogonaux. Cypress utilise un navigateur. Jest utilise un faux DOM et n'est pas éligible aux tests Frontend E2E ou Intergration qui nécessitent un support complet DOM, sauf si utilisé avec Puppeteer ou bien. Une fois que vous avez une bonne idée du type de test que vous écrivez, le choix est assez simple. Si vous avez des difficultés à choisir entre les tests d'unité, d'unité, d'intégration, etc., c'est le problème qui doit être résolu en premier.