Cucumber-js: Le résultat manque le scénario et les balises

Nan. Vous ne pouvez pas accéder facilement aux balises du scénario de test. Il n'est pas prévu de revenir à l'ancien résultat du scénario. Quel est votre cas d'utilisation pour avoir besoin des balises ?

Dans mon cas, j'ai une dépendance au système de balises. Afin d'obtenir des données dans les crochets postérieurs.

Quelque chose comme ça:

<strong i="7">@SuiteName</strong> <strong i="8">@SuiteSectionName</strong> <- These tags tell the suite
Feature: 

<strong i="9">@TC1563697</strong> <- This tag identifies the testcase in the test management tool <strong i="10">@New</strong>
Scenario: 
    Given  
    When 
    Then 

Vous pouvez créer des hooks qui s'exécutent uniquement pour des scénarios avec des balises spécifiques : https://github.com/cucumber/cucumber-js/blob/v3.0.1/docs/support_files/hooks.md#tagged -hooks

J'ai également plusieurs cas d'utilisation pour connaître les balises de scénario. Étant donné l'exemple sudo suivant (syntaxe de version manquante un peu car j'ai des cas de test dans 1.3.1, et je regarde la dernière 3.0.1) :

<strong i="6">@set_video</strong> <strong i="7">@youtube</strong>
Scenario: User should see youtube video

<strong i="8">@set_video</strong> <strong i="9">@vimeo</strong>
Scenario: User should see vimeo video


this.After({tags: @set_video}, function (testCase) {
  let tags = testCase.scenario.tags;

_.forEach(tags, (function (tag) {
 if(tag === '<strong i="10">@youtube</strong>') {
   setVideo('youtube');
 }
if(tag === '<strong i="11">@vimeo</strong>') {
 setVideo('vimeo');
}
});

}

J'ai une balise qui indique quand le crochet doit être exécuté et j'ai d'autres balises qui agissent comme des données pour rendre le crochet plus dynamique pour qu'il fonctionne pour d'autres cas d'utilisation. Sinon, je me retrouve à créer le même hook avec la même logique et à ne changer que les données que je lui transmets. Je trouve que la connaissance des balises est très utile et un outil très puissant pour rendre les crochets plus flexibles.

Puis-je également demander ici, je n'arrive pas à obtenir l'objet de résultat dans le crochet After dans 3.0.1. J'ai essayé testCase, scénarioResult et scénario. Est-ce que j'ai raté quelque chose ?

Nous avons un cas où nous conservons nos cas de test dans TestRail et nous les téléchargeons et les enregistrons en tant que fichiers de fonctionnalités avant l'exécution.

Ensuite, dans le crochet après, nous envoyons les résultats de test détaillés à notre base de données SQL. Ces résultats incluent :

• ID de fonctionnalité de TestRail - extrait d'une étiquette (chaque fonctionnalité a automatiquement généré une étiquette avec l'ID de fonctionnalité)
• exception qui a été levée - prise de scenario.getException() dans le concombre 1.x
• toutes les balises avec lesquelles l'entité est balisée
• étapes qui ont échoué - nous utilisons le crochet stepResult pour obtenir le résultat de chaque étape
• un tas d'autres informations extraites de TestRail à l'aide de l'ID de fonctionnalité tiré des balises

Ainsi, avec le changement actuel de concombre 3.x, nous ne pourrons jamais changer car cela casse complètement notre infrastructure.

@pawelus Mon infrastructure fait exactement la même chose.
On dirait que puisque vous ne perdez rien en effectuant ces actions de manière asynchrone (c'est-à-dire que votre infrastructure de test réelle ne "se soucie pas" de la mise à jour TestRail), vous pouvez déplacer ce code dans un formateur personnalisé et utiliser les informations provenant de l'événement protocole pour construire et envoyer les rapports.

Personnellement, j'ai un script wrapper qui lance le concombre.
Il télécharge les scénarios TestRail avant le lancement du concombre. Ce n'était donc pas un gros problème pour moi de déplacer le code du rapport TestRail des crochets de concombre vers le script wrapper.
Une fois le concombre terminé, le script lit le JSON cucumberResults généré et compile toutes les informations dont il a besoin à partir de là.

On dirait que vous devrez réorganiser votre code de toute façon.
Je pense que déplacer toutes les actions pré/post vers un script wrapper est une bonne solution qui restaure une partie du contrôle que nous avons perdu dans la V3.
C'est toujours un peu pénible, car je dois sérialiser des informations contextuelles importantes pour enrichir les résultats générés (car l'état de mon infrastructure est détruit au moment où le code pertinent s'exécute), mais c'est faisable.

Je pense que perdre la capacité de connaître les balises dans les crochets serait une honte. C'était le seul moyen de rendre un peu plus configurable car vous ne pouvez pas lui transmettre de paramètres. J'ajoutais des balises supplémentaires, puis je voyais celles qui étaient appliquées au scénario actuel pour appeler des fonctions avec différentes entrées.

@yaronassa nous

Nous téléchargeons des fonctionnalités avant que Protractor ne démarre comme vous le faites, mais l'envoi des résultats à la base de données est une autre histoire.

Avec le sharding et les tests exécutés sur la grille Selenium et les rediffusions de fonctionnalités ayant échoué, il sera assez compliqué et une logique complexe d'obtenir les résultats dans le bon ordre dans la base de données. Beaucoup de travail pour restaurer les capacités que nous avions dans le concombre 1 et 2.

De plus, créer un formateur personnalisé uniquement pour obtenir des résultats d'étape ne semble pas correct.

Hé, je suis avec toi.
J'aurais voulu un accès illimité à l'état actuel du concombre - fonctionnalité, scénario et étape, avec toute sa collection de propriétés et un accès en écriture (j'aurais même voulu accéder à la future "pile d'appels" des scénarios, avec la possibilité de la manipuler au préalable ).

Étant donné que cucumberJS s'éloigne délibérément de ce type de "visibilité intérieure", je propose le type de solutions qui, selon moi, peuvent fonctionner dans un avenir prévisible. Personnellement, je pense qu'il viendra un moment où les bricoleurs comme nous devront recourir à des méthodes internes prioritaires dans l'interne de Cucumber pour conserver ce type d'accès.
Et ce n'est pas grave - je suppose que nous sommes une douzaine, et des milliers d'autres utilisateurs occasionnels.

Si possible, je soutiendrais également le nom du scénario. En effet, j'ajoute une capacité d'instantané et j'ai besoin de connaître le nom du scénario pour nommer mes instantanés.

@ gd46, vous pouvez effectuer les opérations suivantes :

this.After({tags: "<strong i="7">@set_video</strong> and @youtube"}, function () {
  setVideo('youtube');
})

this.After({tags: "<strong i="8">@set_video</strong> and @vimeo"}, function () {
  setVideo('vimeo');
})

Cela n'a aucune duplication à part le drapeau @set_video .

@pawelus

Ensuite, dans le crochet après, nous envoyons les résultats de test détaillés à notre base de données SQL.

Avez-vous besoin de le faire dans un crochet After ? Pourriez-vous le faire une fois vos tests terminés en analysant les résultats du formateur json ? Vous pouvez utiliser le formateur de protocole d'événement pour continuer au fur et à mesure que les résultats se produisent, bien que cela nécessite un traitement supplémentaire. Un sous-produit des modifications 3.x est que les résultats de l'analyse sont déplacés des fichiers de support vers des processus autonomes. Je pense que c'est une meilleure séparation des choses et idéalement de la façon dont les choses ont été construites à l'origine.

@bnadim

Vous pouvez ajouter des captures d'écran avec la fonction attach pour qu'elles soient sorties dans les formateurs d'événements potocol / json, puis effectuer un post-traitement pour les enregistrer dans des fichiers en fonction du nom du scénario. Côté non : le nom du scénario n'est pas forcément unique alors que l'uri et le numéro de ligne du scénario le sont.

@charlierudolph Je suppose que c'est une solution de remplacement solide pour mes besoins. Il supprime également le besoin d'analyser le scénario en cours d'exécution. Cela pourrait simplement conduire à définir plusieurs combinaisons de crochets qui tiennent compte des différentes combinaisons qu'une fonction donnée pourrait gérer au sein d'un crochet.

Ainsi, par exemple, j'ai des exemples similaires où j'obtiens les balises des scénarios en cours d'exécution qui les divisent en fonction d'un modèle et utilisent une partie de la correspondance comme paramètre d'une fonction. Dans ces cas, toutes les étapes à suivre sont les mêmes et la seule chose qui change est le paramètre. Cela réduirait donc plusieurs étapes de configuration dans le crochet afin que cela puisse fonctionner dans plusieurs cas.

Un exemple :

tags: <strong i="9">@clear_w2OnlyUser</strong>, <strong i="10">@clear_w2OnlyArcotEnableUser</strong>

I split based on <strong i="11">@clear_</strong> and grab the second half as the parameter. tagName coming from the old scenario result of getTags, getName. 

let profileToClear = tagName.split('<strong i="12">@clear_</strong>')[1];

browser.waitForAngularEnabled(false);
browser.get(url);
login();
navigate();
deleteProfile(profileToClear);

Donnez-moi votre avis à ce sujet ? Je crois que votre exemple serait un remplacement facile dans certains cas. Mais dans d'autres, où plusieurs étapes supplémentaires doivent être effectuées, vous pourriez éventuellement dupliquer toutes ces étapes.

Mon cas d'utilisation est que je configure un mockserver pour chaque scénario, en fonction de la balise que je sais comment il doit se comporter. L'ajout de crochets pour des scénarios balisés spécifiques demande beaucoup de maintenance, car je dois ajouter un crochet pour chaque scénario que je prends en charge...

Nous utilisons également le scénario.name dans nos hooks avant et après afin de consigner le nom du scénario. De cette façon, nous pouvons voir quand un certain scénario commence et se termine lors de l'analyse des résultats des tests. Ce changement casse cette fonctionnalité.

J'utilise Cucumber-js pour piloter Selenium. À la fois local et Browserstack

J'utilisais l'état de test (fonctionnalité, scénario, balises, résultats, etc.) dans les crochets pour de nombreuses choses essentielles.

• avoir des modifications spécifiques au scénario de l'URL
• ignorer dynamiquement les tests en fonction de la configuration actuelle du navigateur
• Utilisez une URL spécifique au scénario pour enregistrer les résultats des tests dans Browserstack
• Utilisez les noms de fonctionnalités et de scénarios pour générer des noms de session dans Browserstack
• Analyser les balises pour identifier et définir la résolution du navigateur spécifique au scénario

Tous ces éléments ont été enveloppés dans des applications pour permettre aux instances simultanées de réduire le temps d'exécution global.

Pourquoi ont-ils été abandonnés ?
Ne reviennent-ils jamais ?

@gd46

Le scénario en cours d'exécution implique-t-il ce type de profil ? Peut-être pourriez-vous faire en sorte que le scénario enregistre le type de profil qui interagit avec le monde, puis vous avez une seule balise claire qui incite à la suppression du profil enregistré ?

@justusromijn

Pour votre serveur fictif, pourriez-vous déplacer la configuration de la balise basée sur l'utilisation d'une étape qui définit la configuration ? Ensuite, vous pouvez paramétrer facilement.

@Jordyderuijter

Vous pouvez enregistrer la ligne de scénario et l'uri (qui est en fait unique et vous évite d'avoir à rechercher le nom du scénario).

@leggebroten

avoir des modifications spécifiques au scénario de l'URL

Vous pouvez utiliser une étape pour cela à la place ou utiliser des balises uniques

ignorer dynamiquement les tests en fonction de la configuration actuelle du navigateur

Comment sautiez-vous dynamiquement les tests ? #912 ajoute un support pour cela

Utilisez une URL spécifique au scénario pour enregistrer les résultats des tests dans Browserstack

Vous pouvez utiliser la ligne et l'uri au lieu du nom. Comme indiqué précédemment, la ligne et l'uri sont garantis uniques alors que le nom ne l'est pas. Je suggère également d'analyser le formateur json ou le formateur de protocole d'événement pour les résultats des tests et d'utiliser des pièces jointes si vous devez ajouter quelque chose.

Utilisez les noms de fonctionnalités et de scénarios pour générer des noms de session dans Browserstack

Vous pouvez utiliser la ligne + URI

Analyser les balises pour identifier et définir la résolution du navigateur spécifique au scénario

Vous pouvez utiliser une étape pour cela.

De tous ces exemples, il me reste encore un cas d'utilisation qui me convainc que nous devrions ajouter des balises ou un nom au crochet. Avoir les balises et le nom semble avoir rendu certaines choses plus faciles à faire, mais je pense qu'il existe d'autres façons de les accomplir qui ont plus de sens pour moi

@charlierudolph merci pour la réponse. Pour le mockserver, j'ai déjà eu une discussion rapide avec des collègues et l'utilisation d'un "arrière-plan" partagé était une solution envisageable, donc oui, vous pouvez traverser celui-ci de la liste.

@charlierudolph Merci pour la réponse.

Bien que vos suggestions d'utilisation des étapes et de la sortie d'analyse puissent fonctionner, elles sont bien inférieures aux versions précédentes où les rappels ont accès à l'état de test.

0) Incohérent avec le modèle Observer. Les rappels doivent recevoir les données dont ils ont besoin pour le comportement qu'ils soutiennent

1) Induit une fragilité

2) L'utilisation des étapes pour modifier l'état viole DRY. Considérez le cas fréquent de l'ajout de tests A/B marqués d'un Tag. À moins que vous n'ajoutiez une extension de ligne de commande pour exécuter des tests en fonction des étapes qu'ils incluent, les tests nécessiteront les DEUX balises et leurs étapes de modification d'état.

3) Nécessite que le développeur fasse un travail supplémentaire. L'analyse de la sortie pour trouver l'état est inutile, fastidieuse, sujette aux erreurs, lie les tests aux formats de sortie (couplage médiocre) et viole DRY.

4) Incohérent avec le concombre. L'ajout d'étapes (une partie sémantique du test) pour modifier l'état de la fonctionnalité va à l'encontre de l'intention de Cucumber d'isoler le rédacteur de test. Si le comportement n'a pas changé, le test ne devrait pas le faire.

5) Ce n'est pas déclaratif. Les balises sont des métadonnées À PROPOS du test, il est sémantiquement cohérent de les utiliser pour modifier l'état dans lequel le test sera exécuté. Alors que les étapes sont intégrées dans le test. Vous identifiez un ensemble de tests par leurs balises… et non par les étapes qu'ils utilisent.

Oh, et je n'étais pas en train de "sauter" les tests, j'utilisais callback( null, 'pending' ) pour éviter d'exécuter le test. La nouvelle fonction « sauter » est une solution supérieure.

@charlierudolph , je pensais, une autre solution ...
lors de la construction de l'objet World, fournissez une référence à l'objet Scénario utilisé pour le test.

Étant donné que le monde est disponible en tant que "ceci" pour tous les rappels, il atteindrait la parité complète avec V2 (à condition que le rappel AfterAll ait reçu les résultats)

@leggebroten

1. Je n'ai jamais entendu le motif d'observateur être un objectif de conception pour le concombre.
2. Les noms de scénario sont également fragiles car un seul changement de personnage le modifie également. J'accepte la rupture de numéro de fichier/de ligne lorsque je prends ce qui semble être des actions sans rapport. Je suggérais l'utilisation dans le rapport des résultats et non dans l'exécution des tests et donc la partie fragile n'a pas beaucoup d'effet négatif.
3. Using Steps to alter State violates DRY Je ne comprends pas. La balise est utilisée pour sélectionner les fonctionnalités et l'étape est utilisée pour la configuration/les actions/les attentes. Ce sont des finalités différentes. Nous avons une prise en charge minimale de l'utilisation de la balise pour la configuration avec des crochets étiquetés, mais elle n'est pas conçue pour gérer la complexité.
4. Je ne suggérais que l'analyse de la sortie du formateur pour les rapports. Cela ne devrait pas être impliqué dans l'exécution des tests.
5. Adding Steps (a semantic part of the test) to alter the Feature's state is counter to intent of Cucumber of isolating test writer Je ne comprends pas non plus. Si vous ne pouvez pas utiliser les étapes pour effectuer des actions et définir l'état, comment exécutez-vous les tests ?
6. Tags are metadata ABOUT the test, it is semantically consistent to use them to alter the state in which the test will run . Je ne suis pas d'accord sur le fait que cela soit cohérent. Les balises pour moi ne servent qu'à identifier les tests. Il existe un support pour une modification d'état minimale, mais pas pour une modification d'état complexe avec des paramètres.

Il n'y a plus d'objet scénario dans le système. Je ne pense pas que la parité avec la v2 devrait être un objectif. Je suis content que cette conversation ait eu lieu et je cherche d'autres solutions, mais je ne veux pas revenir à ce que nous avions auparavant car je pense que cela obligeait les utilisateurs à se fier beaucoup plus à la mise en œuvre de concombre et non à son interface.

@charlierudolph ,

Merci d'avoir pris le temps de discuter de ce problème. J'apprécie vraiment le travail que vous avez fait pour nous fournir Cucumber-js. Mais en l'état, je ne peux pas passer à la V3.

Je n'ai pas l'intention d'être combatif. Je suis juste inquiet et cela peut apparaître dans mes réponses.

En utilisant uniquement l'interface d'événement documentée de la version précédente, j'ai construit un cadre qui réduit considérablement le temps d'exécution global des tests en permettant aux fonctionnalités d'être exécutées simultanément sur une énorme matrice de test configurable comprenant les systèmes d'exploitation/versions, navigateurs/versions, bureau/ Tests mobiles et Optimizely A/B.

JE NE PEUX PAS utiliser les étapes. C'est trop tard. Le type d'appareil, le système d'exploitation/la version et le navigateur/la version DOIVENT être déterminés avant le début du test, sinon chaque scénario sera forcé d'avoir une étape "configuration du système d'exploitation" et une étape "configuration du navigateur". Ceci est en conflit direct avec les objectifs de Cucumber.

Alternativement, comme je l'ai mentionné précédemment, vous pouvez fournir les informations du scénario (URI de la fonction, nom, ligne et balises) au constructeur World. Ceci est sémantiquement cohérent avec l'intention de l'objet World et plus simple à encapsuler et à étendre. Non seulement cela éliminera la plupart de mes gestionnaires d'événements, mais parce que le "ceci" du gestionnaire est l'objet World, son état est cohérent avec le modèle d'observateur.

1. Je n'ai pas dit que l'Observer Pattern était un objectif de conception pour Cucumber. Simplement que les crochets et les événements sont des observateurs et que, en tant que tels, ils devraient recevoir l'état dont ils ont besoin pour faire leur travail. Ce modèle permet la séparation entre l'implémentation de l'appelant et les gestionnaires d'événements.

2. Je n'ai aucune dépendance sur les noms réels. Mais comme ils sont uniques, ils sont le moyen de créer le nom de session associé significatif pour l'utilisateur dans Browserstack.

3. Avoir accès à l'ensemble des balises pendant Before m'a permis de créer des constructions réutilisables pour modifier l'état (comme la définition des paramètres d'URL Optimizely) sans modifier le test (ajout d'étapes). Cela signifiait qu'il y avait une corrélation 1-1 entre les tests que je voulais exécuter (Tags) et leur configuration. SÉCHER.

4. Vous avez exprimé la crainte que les développeurs deviennent dépendants de la mise en œuvre, mais votre solution pour supprimer l'état d'observateur nécessaire consiste à rendre le développeur dépendant d'une autre mise en œuvre (format de fichier) ? Comment forcer un utilisateur à faire des fichiers d'analyse de travail BEAUCOUP plus fastidieux, lents et sujets aux erreurs peut-il être meilleur que d'accéder à une propriété d'État ?

5. De toute évidence, les étapes définissent l'état de test. Mais l'un des objectifs de conception de Cucumber était que la personne écrivant les étapes soit isolée de l'implémentation sous-jacente. EG teste le comportement sémantique sans s'embourber dans les détails sous-jacents. L'ajout d'étapes pour modifier les paramètres de requête et la définition de périphérique/navigateur/système d'exploitation semblent aller à l'encontre de cet objectif.

6. Pour vous, les tags ne servent qu'à identifier les tests. Mais Cucumber Wiki a de nombreuses utilisations pour les balises.

7. Organiser et regrouper
8. Filtres (exécution des ensembles via la ligne de commande)
9. Liens vers des documents connexes (tels que les indicateurs Optimizely)
10. Indiquer où dans le processus la caractéristique est

Avoir accès aux balises pendant le rappel Avant me permet de garantir l'état approprié en fonction de la configuration du navigateur utilisé pour conduire le test. L'utilisation de balises rend cela déclaratif. L'utilisation des étapes obscurcit l'intention

Les appels et les paramètres des gestionnaires d'événements dans les versions précédentes étaient l'interface. Si les développeurs associent leur code à votre implémentation qui fuit, transmettez un proxy « scénario » en lecture seule aux gestionnaires d'événements.

@charlierudolph merci pour ta réponse

Les noms de scénario sont également fragiles car un seul changement de personnage le modifie également. J'accepte la rupture de numéro de fichier/de ligne lorsque je prends ce qui semble être des actions sans rapport. Je suggérais l'utilisation dans le rapport des résultats et non dans l'exécution des tests et donc la partie fragile n'a pas beaucoup d'effet négatif.

Certes, les noms de scénarios sont également fragiles, mais c'est un moyen beaucoup moins fragile de référencer des scénarios que de les référencer par fichier et par ligne. Nous utilisons quotidiennement les noms de scénario dans la journalisation pour analyser les échecs de l'exécution et voir ce qui s'est mal passé. Si la journalisation n'affiche que le numéro de fichier et de ligne, cela entraînera beaucoup trop de surcharge pour retracer le scénario. En plus de cela, si quelqu'un a apporté des modifications au fichier de fonctionnalités ou déplacé le scénario ailleurs entre-temps, cela deviendra encore plus compliqué.

Si la journalisation n'affiche que le numéro de fichier et de ligne, cela entraînera beaucoup trop de surcharge pour retracer le scénario.

Comment est-ce plus de frais généraux? Vous connaissez le numéro de fichier et de ligne et pouvez vous y rendre directement. Si vous avez le nom du scénario, vous devez rechercher cette chaîne à transférer dans ce fichier et cette ligne.

Comment est-ce plus de frais généraux? Vous connaissez le numéro de fichier et de ligne et pouvez vous y rendre directement. Si vous avez le nom du scénario, vous devez rechercher cette chaîne à transférer dans ce fichier et cette ligne.

Comme je l'ai dit, si le fichier de fonctionnalité a changé entre-temps et que le scénario n'est plus positionné sur cette ligne. Surtout quand je regarde dans les journaux d'un ancien test (par exemple il y a 1 semaine). Dans ce cas, je devrais passer par git et voir quel scénario était sur cette ligne à un moment donné.

FWIW, cucumber-ruby a deux points d'extension qui, à mon avis, satisfont au principe "les choses faciles devraient être faciles, les choses difficiles devraient être possibles" et pourraient être des idées qui pourraient aider avec ces cas d'utilisation.

Tout d'abord, nous passons une instance de RunningTestCase à chaque hook. Il s'agit d'un objet à valeur immuable qui contient toutes les informations sur la source Gherkin (scénario / contour / tags, etc.) ainsi que l'état actuel des résultats du scénario. Être immuable signifie que nous sommes protégés contre les cas où l'utilisateur pourrait essayer de changer les choses sur nous, mais cela leur donne également une transparence sur l'état actuel des choses.

Deuxièmement, nous avons des filtres . Les filtres vous permettent de manipuler le flux de cas de test avant qu'ils ne soient exécutés. Nous utilisons des filtres pour, par exemple, supprimer les cas de test du flux qui ne correspondent pas au modèle de balise spécifié sur la CLI. Les filtres sont une fonctionnalité pour les utilisateurs avancés.

HTH

Je viens de réaliser que la documentation derrière ce lien pour les filtres est terrible ! Désolé. Pas le temps de le réparer maintenant, mais il y a d'autres exemples ici : http://www.rubydoc.info/github/cucumber/cucumber-ruby/Cucumber/Filters

Salut @charlierudolph ,

Désolé ça fait un moment que je n'ai pas suivi cette conversation. Peux-tu préciser ta déclaration :

« Le scénario en cours d'exécution implique-t-il ce type de profil ? Peut-être pourriez-vous faire en sorte que le scénario enregistre le type de profil qui interagit avec le monde, puis vous avez une seule balise claire qui incite à la suppression du profil enregistré ? »

Je ne suis pas sûr de suivre.

Et je comprends qu'il existe peut-être d'autres moyens d'obtenir la même solution sans l'ancien résultat du test. Mais d'après ce que j'ai vu jusqu'à présent dans cette conversation, toutes les alternatives semblent plus complexes qu'elles ne devraient l'être. L'ancien résultat du test contenait de nombreuses données descriptives sur le scénario qui était sur le point de se dérouler et c'était le seul moyen d'avoir des crochets "paramétrés". Le rapporteur tel qu'il ressort de ce que j'ai vu et essayé ne prend actuellement pas en charge l'exécution d'une fonctionnalité à partir d'un numéro de ligne de scénarios. Donc, le nouveau résultat testCase n'a pas grand-chose que je trouve utile à part le statut.

J'aimerais voir testCase correspondre au résultat renvoyé lors de l'utilisation de getTestCasesFromFileSystem avec PickleFilter. J'ai utilisé cela pour faire un travail parallèle intéressant pour prendre en charge le filtrage des scénarios par balise à transmettre au rapporteur en tant que fragments. Les informations renvoyées par ce résultat sont beaucoup plus utiles et je pense qu'il serait extrêmement utile d'avoir dans le résultat testCase.

Exemple de résultat de PickFilter :

{ pickle: 
     { tags: [Object],
       name: 'Github test with page object',
       language: 'en',
       locations: [Object],
       steps: [Object] },
    uri: 'test/features/examples/github-example.feature' }

Je ne dis pas que cela doit correspondre exactement, mais je vois beaucoup dans ce résultat dont d'autres ici et moi sembleraient bénéficier.

Si vous êtes intéressant dans mon exemple, je l'utilise ici : https://github.com/gd46/dibellag-automation-framework/blob/master/configuration.js#L91

@charlierudolph Est-ce là que testCase est défini ?

https://github.com/cucumber/cucumber-js/blob/fbff6b0fae54d2e341ee247addc60a9f05753f1d/src/formatter/helpers/event_data_collector.js#L22

D'après ce que je peux dire, il y a une référence au pickle le long du testCase. Alors pourquoi ne pas renvoyer quelques bits supplémentaires du résultat du cornichon sur le résultat testCase ?

@ gd46 d' accord, ajoutons pickle à l'objet qui est passé au crochet remplaçant sourceLocation. Cela doit être mis à jour dans cette fonction : https://github.com/cucumber/cucumber-js/blob/master/src/runtime/test_case_runner.js#L153

Salut @charlierudolph , je viens de voir ton commentaire. Ce serait génial! J'essaierai d'y jeter un œil prochainement. Je serais heureux d'apporter ma contribution.

@charlierudolph Je voulais juste clarifier le changement. Sommes-nous d'accord avec la différence que pickle contient uri sans le numéro de ligne directement dessus, comme le fait sourceLocation. Et si quiconque souhaite consommer l'uri avec le numéro de ligne, il peut utiliser les numéros de ligne renvoyés par l'objet pickle ? Je ne vois aucun problème avec cela, je voulais juste confirmer.

Je suppose que laissons l'objet d'emplacement source tel quel (au lieu de le supprimer) et ajoutons l'objet cornichon.

Ok ça marche aussi pour moi. Donc, je suis nouveau pour contribuer au concombre, j'essaie toujours de comprendre la structure.

Comme vous l'avez souligné la ligne qui doit être mise à jour, je pense que nous pouvons simplement ajouter quelque chose comme ceci à côté de sourceLocation :

pickle: this.testCase.pickle

Ensuite, toute personne souhaitant le consommer dans le hook peut y accéder comme suit :

testCase.pickle.tags
testCase.pickle.name
etc. 

J'ai fait la mise à jour mais je ne sais pas à 100% comment mettre à jour tous les tests associés. Seriez-vous en mesure de fournir des conseils?

J'ai pu tester le changement en liant mon fork aux modifications apportées à l'un de mes projets locaux. Le résultat testCase complet ressemblera à ceci :

{
  "sourceLocation": {
    "uri": "test\/features\/examples\/example.feature",
    "line": 4
  },
  "pickle": {
    "tags": [
      {
        "name": "@example",
        "location": {
          "line": 3,
          "column": 3
        }
      }
    ],
    "name": "Custom Transform should take belly and capitalize it",
    "language": "en",
    "locations": [
      {
        "line": 4,
        "column": 3
      }
    ],
    "steps": [
      {
        "text": "I have cucumbers in my belly",
        "arguments": [

        ],
        "locations": [
          {
            "line": 5,
            "column": 10
          }
        ]
      }
    ]
  },
  "result": {
    "duration": 7,
    "status": "passed"
  }
}

Après avoir effectué quelques tests supplémentaires, j'ai remarqué que pickle ne contient pas d'uri au moment où nous y avons accès dans test_case_runner. Je pense donc que c'est bien de garder l'emplacement de la source tel quel.

C'est ce que PickleFilter renvoie pickle comme :

{
    "pickle": {
      "tags": [
        {
          "name": "@example",
          "location": {
            "line": 3,
            "column": 3
          }
        }
      ],
      "name": "Custom Transform should take belly and capitalize it",
      "language": "en",
      "locations": [
        {
          "line": 4,
          "column": 3
        }
      ],
      "steps": [
        {
          "text": "I have cucumbers in my belly",
          "arguments": [

          ],
          "locations": [
            {
              "line": 5,
              "column": 10
            }
          ]
        }
      ]
    },
    "uri": "test\/features\/examples\/example.feature"
  }

Donc, tout sera pareil, moins le cornichon n'aura pas d'uri dedans.

Ouverture d'un PR pour mettre en évidence les changements jusqu'à présent. Encore faut-il mettre à jour les tests.

Travail sur la mise à jour des tests. J'ai configuré cette chose pour changer ma version java locale et j'ai réalisé que c'est pourquoi je n'ai pas pu exécuter certains tests de fonctionnalités :/.

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.