Cucumber-js: résultat du scénario non transmis aux hooks avant/après

J'ai été mordu par ça. Notre mise à niveau vers 3 sur le concombre pro est en attente à cause de cela.

https://github.com/cucumber/cucumber-js/blob/fbff6b0fae54d2e341ee247addc60a9f05753f1d/src/runtime/test_case_runner.js#L109 le coupable ?

Quelle partie de cela est nécessaire exactement? Utilisez-vous uniquement les prédicats de statut ? Cela semble être la seule chose utilisée dans les documents entourant ce

Nous utilisons actuellement scenarioResult.status , scenarioResult.scenario.uri et scenarioResult.scenario.line .

@jbpros votre cas d'utilisation suit-il les exemples que nous avons actuellement à ce sujet (enregistrer une capture d'écran lorsqu'un scénario échoue) ? J'ai toujours pensé que c'était vraiment bizarre que le scénario soit passé en crochets et j'aimerais trouver une façon différente de gérer cela.

Actuellement, je pense que nous ajoutons une nouvelle fonction de code de support : onFailedTestStep qui vous permet de définir une fonction à appeler avec un échec de test. Il serait appelé avec le même argument mondial que l'étape échouée et vous pourriez donc attacher une image ou quelque chose comme ça. Nous pourrions créer un module dédié pour analyser les pièces jointes à partir du formateur de protocole d'événement et les copier dans un dossier.

En tant qu'utilisateur bricoleur, je voudrais qu'une telle fonction / gestionnaire / objet ait autant de contexte que possible. Même sans quelque chose de grandiose comme l'ensemble du passé et du futur (https://github.com/cucumber/cucumber-js/issues/875), il serait extrêmement utile de savoir quelle est l'étape et le scénario actuels pour chaque échec.
Par exemple, cela me permet de contrôler les procédures de restauration en fonction des balises, ou simplement de voir quelles autres étapes ont été exécutées avant celle qui a échoué.

Je vous exhorte à envisager de les transmettre à onFailedTestStep , si c'est la solution que vous recherchez.

Les Hook Docs doivent également être mis à jour - le lien du premier paragraphe vers ScenarioResult est un 404.

Plutôt que onFailedTestStep , pourquoi ne pas définir un hook appelé AfterStep ? Cucumber-Ruby a cela depuis longtemps et comme vous le savez, la cohérence est importante.

@aslakhellesoy Je veux me concentrer sur le cas d'utilisation et m'assurer que nous le résolvons de la bonne manière.

La cohérence est importante, mais cela ne signifie pas que nous devons tout copier simplement parce qu'il existe ailleurs. Nous devrions évoluer à mesure que nous déterminons de meilleures façons de gérer les choses

Pouvez-vous ou @mattwynne ou quelqu'un de l'équipe ruby ​​nous éclairer sur la raison pour laquelle AfterStep a été conçu et à quoi il sert ?

Je ne suis pas de l'équipe ruby ​​donc je ne sais pas pour quoi AfterStep été construit, mais personnellement j'utilise AfterStep pour faire diverses opérations. Voici quelques exemples:

1. Prenez une capture d'écran et affichez le journal du navigateur sur les scénarios ayant échoué
2. Effectuez une journalisation supplémentaire pour certains projets, qu'ils aient échoué ou non
3. Nettoyer

Pour nous, nous aurons besoin que le scénario et le résultat soient transmis à AfterStep toute façon pour effectuer une journalisation supplémentaire. Je suis sûr qu'il existe d'autres cas d'utilisation qui en ont besoin dans AfterStep , que nous n'avons même pas envisagés.

Cela signifie que s'il y avait quelque chose comme onFailedTestStep , nous aurons plus d'une façon d'obtenir la même chose : une pour utiliser AfterStep et l'autre pour utiliser onFailedTestStep .

Cela peut également entraîner des incohérences au sein des projets en fonction de la personne qui a mis en œuvre le crochet ; certains peuvent utiliser AfterStep tandis que d'autres peuvent utiliser onFailedTestStep . Je ne pense pas que l'un ou l'autre de ceux-ci soit souhaitable.

@charlierudolph

Je veux comprendre d'où vous venez. Pourriez-vous expliquer pourquoi vous pensez ce qui suit ?

J'ai toujours pensé que c'était vraiment bizarre que le scénario soit passé en crochets

Je n'ai jamais vraiment aimé le mélange des deux paradigmes. Les hooks avant/après sont liés à la configuration/démontage avec l'exécution réelle des tests. L'utiliser pour faire également des rapports semble être quelque chose qui devrait être pris en charge séparément

Prenez une capture d'écran et affichez le journal du navigateur sur les scénarios ayant échoué

Si vous faites cela dans AfterStep, cela est fait pour les étapes ayant échoué, et non pour les scénarios ayant échoué. C'est pourquoi tous les exemples du référentiel utilisent l'objet scénario et c'est pourquoi je souhaite créer un nouveau crochet pour ce cas d'utilisation spécifique. Je n'ai entendu aucun autre cas d'utilisation convaincant.

Effectuez une journalisation supplémentaire pour certains projets, qu'ils aient échoué ou non

Quel type de journalisation supplémentaire effectuez-vous ?

Nettoyer

Qu'y a-t-il à nettoyer après une étape?

Pour nous, nous aurons besoin que le scénario et le résultat soient transmis à AfterStep de toute façon pour effectuer une journalisation supplémentaire. Je suis sûr qu'il existe également d'autres cas d'utilisation qui en ont besoin dans AfterStep, que nous n'avons même pas envisagés.

J'essaie de collecter ces cas d'utilisation. Parfois, les gens peuvent l'utiliser lorsqu'il existe d'autres façons de le faire ou comme solution de contournement pour quelque chose pour lequel nous pourrions intégrer un meilleur support.

Cela signifie que s'il y avait quelque chose comme onFailedTestStep, nous aurons plus d'une façon d'obtenir la même chose : une pour utiliser AfterStep et l'autre pour utiliser onFailedTestStep.

Cucumber-js n'a actuellement pas de AfterStep et je ne prévois pas d'implémenter les deux.

Je suis en train d'essayer d'obtenir le support du concombre 3 dans le cadre du rapporteur-concombre et je pourrais vraiment utiliser un AfterStep . Je me rends compte qu'une bibliothèque qui colle deux autres bibliothèques ensemble n'est pas le cas d'utilisation le plus courant, mais cela le rendrait beaucoup plus simple. J'essaie de comprendre comment le faire avec les nouveaux éléments du protocole d'événement, mais je n'obtiens aucun contexte de fonctionnalité/scénario/étape dans aucun des événements *-finished . Nous utilisons les noms, les uri et les numéros de ligne de la fonctionnalité, du scénario et des étapes pour rendre compte au rapporteur et donner aux intégrations IDE (Intellij) quelque chose à afficher et à parcourir dans leur arborescence. Mon 0,02 $ en tout cas.

Juste pour mentionner que toutes les fonctionnalités discutées (et bien plus encore) peuvent être accomplies avec setDefinitionFunctionWrapper .
Vous pouvez envelopper toutes les étapes avec des actions pré/post, qui vous permettent non seulement de réagir aux entrées et sorties d'une étape, mais même de les muter.

Ainsi, par exemple, je l'utilise pour implémenter une étape "La prochaine étape devrait échouer avec l'erreur XYZ", ce qui me permet d'implémenter rapidement des vérifications négatives approfondies et des simulations d'erreurs sans implémenter d'étapes négatives en double ou une gestion spéciale des erreurs à chaque étape. .

Je pense qu'il n'y a rien qu'un crochet AfterStep puisse faire que setDefinitionFunctionWrapper ne puisse pas faire.

Des mises à jour à ce sujet ? Essayer de mettre à niveau de 2.0.0 à 3.0.0 au travail et toujours pas défini pour le scénarioRésultat

@paul-phillips-ark oui, voir #905. Si vous voulez aider à le faire avancer, vous pouvez bifurquer et soumettre un nouveau pr qui répond aux commentaires de @charlierudolph .

Lorsque je console.log(scenarioResult), je ne suis toujours pas défini dans les fonctions Avant et Après ? Est-ce que j'ai raté quelque chose ? Toutes nos excuses si le commentaire ci-dessus sonne de manière dense.

Mes cas d'utilisation sont actuellement les suivants :

Avant chaque scénario, je demande des appareils qui remplissent ma base de données pour les tests. Chaque fonctionnalité a son propre ensemble de luminaires nécessaires pour cela. Le chemin de l'appareil sur le serveur répète le chemin de la fonctionnalité, j'ai donc également besoin uri option

Before({ timeout: 60 * 1000 }, scenarioResult => {
    ...
    const file = scenarioResult.scenario.feature.uri;
    ...
});

Sur After hook autant d'entre nous que je fais une capture d'écran :

After(scenarioResult => {
    if (scenarioResult.status === 'failed') {
      driverUtils.takeScreenShot(scenarioResult.scenario.name);
    }
});

@charlierudolph pourriez-vous couper une version avec la pull request #905 comme solution provisoire ? cela nous permet de terminer la transition de la v2 à la v3 - qui est actuellement bloquée en raison de cette régression/changement. votre refactorisation proposée pourrait entrer dans une autre demande d'extraction.

Il y a quelques problèmes pour #905 mais je vais essayer d'obtenir un correctif et de faire une version ce week-end.

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