Cucumber-js: Crochets et hacks avant/après

Il n'appellera pas After lorsque des entités consécutives ont la même balise.

Je ne comprends pas. Pouvez-vous s'il vous plaît donner plus de détails à ce sujet? Vous pouvez créer un hook After spécifique à la balise présente ou non. Notez que la syntaxe de la balise a changé depuis que cette solution de contournement a été donnée.

Il n'appellera pas After si la fonctionnalité balisée était le dernier test de la génération.

Encore une fois, je ne comprends pas cela, veuillez expliquer davantage. Vous devriez pouvoir utiliser un hook After, mais vous perdez le contexte de savoir s'il s'agit ou non du dernier. Idéalement, vous n'avez pas besoin de faire de démontage ici.

Vous essayez également de créer des scénarios connectés, ce qui est déconseillé. Je suggérerais l'un des éléments suivants :

• déconnecter les scénarios
• exécuter concombre-js plusieurs fois en chargeant différents fichiers de support et utiliser BeforeAll / AfterAll

Pour être clair, la solution de contournement à laquelle je fais référence est:

this.Before({ tags: ['<strong i="6">@featurehook</strong>'] }, function () {
  // log user in (if needed)
})

this.Before({ tags: ['~<strong i="7">@featurehook</strong>'] }, function () {
  // log user out (if needed)
})

Considérez certaines fonctionnalités :

<strong i="11">@featurehook</strong>
Feature: feature 1
   Scenario: scenario 1

<strong i="12">@featurehook</strong>
Feature: feature 2
   Scenario: scenario 2

Feature: feature 3
   Scenario: scenario 3

<strong i="13">@featurehook</strong>
Feature: feature 4
   Scenario: scenario 4

S'ils sont exécutés dans l'ordre ci-dessus, le démontage ne se produira pas entre la fonctionnalité 1 et la fonctionnalité 2. Le démontage ne se produira pas non plus après la fonctionnalité 4 car il n'y aura pas d'autre correspondance de test ~ @featurehook (il est vrai que cela peut être corrigé avec Après tout).

Je ne cherche pas à faire des scénarios connectés, pour moi c'est être libre de décider d'un compromis entre isolation et performance.

Prenons l'exemple d'un test qui met en place un serveur SMTP test avec différentes configurations :

<strong i="20">@smtpConfig1</strong>
Feature: ....

<strong i="21">@smtpConfig2</strong>
Feature: ....

Il peut y avoir des effets secondaires entre les scénarios en ne le détruisant pas, mais le compromis entre pureté et performance pourrait en valoir la peine dans ce cas.

Désolé, mais je pense que ce n'est pas quelque chose qui devrait être pris en charge. Il est possible de partager l'état dans tous les scénarios et dans un seul scénario qui couvre la grande majorité des cas. Votre exemple dans le dernier commentaire (avec @featurehook) n'est pas résolu en ayant BeforeFeature / AfterFeature de toute façon.

+1 pour les hooks BeforeFeature/AfterFeature
Je suis d'accord avec la nécessité d'équilibrer les performances avec l'isolement des tests. De la façon dont le cadre est construit actuellement, il y a très peu de choses qui relient les scénarios en une seule fonctionnalité, à l'exception des étapes d'arrière-plan qui sont répétées. Dans certains cas, nous ne souhaitons peut-être pas que les étapes d'arrière-plan soient répétées, mais plutôt qu'elles se produisent une fois au début de la fonctionnalité et qu'elles ne soient supprimées qu'une fois tous les scénarios terminés.

Depuis que j'utilise un service comme Browserstack, qui est perpétuellement lent et pénible à utiliser (tout comme d'autres fournisseurs de serveurs distants comme Saucelabs), j'utilise normalement les gestionnaires d'événements BeforeFeature et AfterFeature pour configurer les sessions de sélénium et le démontage par fichier de fonctionnalité.

Par conséquent, les scénarios liés à cette fonctionnalité mentionnée dans mon fichier s'exécutent ensemble et pour recommencer après chaque scénario, j'actualise l'écran du navigateur et l'état de mon application est actualisé pour mes tests. Donc, d'une certaine manière, ils sont isolés et cela n'affecte pas non plus les performances du test.

Cela devrait être considéré comme un cas pour ramener les crochets de fonctionnalité Avant/Après à être utilisés plutôt que d'exécuter cucumberjs par fichier de fonctionnalité comme suggéré ci-dessus.

Les hooks BeforeFeature/AfterFeature sont essentiels pour les tests e2e/uat/bdd/call-it-whatever-you-want pour lesquels le concombre est fait.

Les principaux "concurrents" de Cucumber le supportent (par exemple JBehave, RobotFramework), et sans aucun hack ; c'est une caractéristique appropriée du cadre.

Ce problème est définitivement un obstacle à l'utilisation de Cucumber.

Salut... Je suis confronté à un problème lié à cela. Dans mon cas, j'utilise des hooks avant et après balisés pour créer/supprimer des données qui seront utilisées pour tester l'interface utilisateur. Dans le hook Avant, j'ai atteint un point de terminaison d'API et créé les données, et dans le crochet Après, j'ai atteint un autre point de terminaison d'API pour le supprimer (j'enregistre l'identifiant des objets renvoyé dans la réponse de création, puis je crée la charge utile de suppression avec ces identifiants )

Le problème est que, lorsque le scénario qui utilise ces données (et déclenche les crochets) est le dernier à être exécuté, le crochet après n'est jamais déclenché...

Un moyen de contourner ce problème ?

Merci

+1 pour la fonctionnalité Avant et Après.
Notre cas d'utilisation est le suivant : nous trouvons des bogues dans certains navigateurs qui n'apparaissent pas dans d'autres.

Nous voulons taguer une fonctionnalité comme suit :

@ie-8-only
Business Need: IE8 should have limited functionality, but what is displayed, should be displayed correctly

@no-access @ssl-insecurity <strong i="8">@security</strong> @BUG-1876
Scenario: No access
   Given I am on the home page
   When I see that my browser is not supported
   Then I should not be able to access the core site functionality

@formatting-issue <strong i="9">@bugs</strong> @BUG-1210
Scenario: The menu should not be formatted like a staircase
   For the users to be able to navigate to the about us / contact us area of the site, the site navigation should be active
   Given I am on the home page
   When I see the menu
   Then it should be displayed in a line

Cela nous permettra de fermer le navigateur et d'ouvrir IE dans un crochet BeforeFeature, et de rouvrir le navigateur que nous utilisons pour le reste de la suite dans le crochet AfterFeature. La fermeture et la réouverture du navigateur prennent beaucoup de temps lorsque vous le faites pour chaque scénario, ce qui en ferait une fonctionnalité intéressante à utiliser.

Noter:
Je sais qu'il existe des alternatives qui impliquent l'objet world (définir le navigateur actuel ici, et ne se fermer que si le navigateur n'est pas ce dont nous avons besoin dans le crochet beforeAll pour ceux-ci), mais il semble plus simple de le faire de cette façon, et il doit être déjà fait dans un crochet ou Selenium décide qu'il va lancer une crise de sifflement la moitié du temps.

Il y a d'autres moments où vous voudrez peut-être joindre du texte à la fonctionnalité en tant que description supplémentaire pour celle-ci dans un crochet BeforeFeature, qui est un autre exemple où cela serait utile

Je pense aussi que les crochets de fonctionnalités avant/après seraient utiles sur certains types de tests. Par exemple, Specflow, la bibliothèque Cucumber pour .NET, les a implémentés :
https://specflow.org/documentation/Hooks/

Ce fil a été automatiquement verrouillé puisqu'il n'y a eu aucune activité récente après sa fermeture. Veuillez ouvrir un nouveau problème pour les bogues associés.