Cucumber-js: implémenter --réessayer

@ericyliu Il arrive dans le concombre 3. Je ne sais pas pourquoi Cucumber 2 est toujours en RC cependant ... il est sorti depuis 2 ans

@charlierudolph ou n'importe qui si vous aviez des conseils, je serais heureux de le ramasser et de l'

Mon approche présomptive serait qu'à la fin d'un scénario en cours d'exécution, nous pouvons dire s'il a échoué ou non et le réexécuter (en conservant un état pour le décompte des nouvelles tentatives). Où puis-je m'accrocher à ça ?

En plus de cela, je m'attendrais à ce qu'à la fin de l'ensemble du processus, je puisse accéder à une liste de tous les scénarios, le nombre de fois qu'ils ont réessayé et leurs statuts finaux afin que cela puisse être a) enregistré et b) vidé sur le disque si vous le souhaitez .

Clôture car je ne veux personnellement pas mettre en œuvre cela car je ne suis pas d'accord avec cela. Je n'aime pas fournir une fonctionnalité qui peut être utilisée pour traiter un test de scintillement au lieu de corriger la cause du scintillement.

??

@charlierudolph il est parfois impossible de gérer les tests de scintillement. Par exemple, dans notre environnement, nous avons 23 services différents auxquels notre application accède, et comme nous ne possédons pas ces services, aucun d'entre eux peut être en panne à un moment donné. l'indicateur --retry nous permet de réexécuter le test afin qu'une panne de service temporaire (lorsqu'ils redémarrent le service) ne provoque pas l'échec de notre suite de tests.

En ce qui concerne le désaccord personnel avec cette fonctionnalité (cet argument peut être aussi vain que les onglets contre les espaces dans le monde de l'ingénierie), si Cucumber en tant que spécification d'outillage l'implémente, nous devrions également le prendre en charge dans la version JS de cet outil.

C'est aussi dans le monde réel avec de larges suites de tests et des applications complexes impossibles à défendre à 100 % contre l'écaillement et devient donc incroyablement coûteux. Absolument, vous pouvez avoir un parcours d'ingénierie pour l'améliorer, mais je doute qu'il existe de nombreuses entreprises avec le luxe de ressources pour soutenir un tel effort avec un retour sur investissement décent.

Dans le monde réel, il est extrêmement précieux de pouvoir réessayer les tests ayant échoué avec l'ajout d'un bon suivi pour identifier les flocons pour une action proactive.

J'apprécierais que nous reconsidérions la décision de clore ce problème et, comme indiqué précédemment, je suis plus qu'heureux de travailler dessus avec quelques conseils.

Pour ajouter à cela, cucumber-js already a une fonctionnalité rerun qui est fondamentalement juste une nouvelle tentative mais moins efficace car elle doit être exécutée en tant que processus séparé (cela permet de le comprendre correctement). Réessayer est une solution beaucoup plus agréable.

cc @charlierudolph

C'est aussi dans le monde réel avec de larges suites de tests et des applications complexes impossibles à défendre à 100 % contre l'écaillement et devient donc incroyablement coûteux.

Je déteste absolument les tests floconneux. Sur mes projets actuels, j'essaie de m'éloigner de l'exécution de tout test floconneux sur CI et de les enregistrer pour des exécutions manuelles où, si quelque chose échoue en raison d'un floconnage, vous pouvez le réexécuter ou le vérifier manuellement. Cela dépend de la recherche de votre source de desquamation et de la limitation du nombre de tests qui doivent y faire face.

Pour ajouter à cela, cucumber-js a déjà une fonctionnalité de réexécution qui est fondamentalement juste une nouvelle tentative mais moins efficace car elle doit être exécutée en tant que processus séparé (cela permet de le comprendre correctement). Réessayer est une solution beaucoup plus agréable

Rerun a été conçu pour que vous puissiez facilement vous concentrer sur les tests qui doivent être corrigés. Oui, vous pouvez l'utiliser pour réessayer uniquement les scénarios ayant échoué.

Je suis d'accord à 100% avec le fait que les tests floconneux soient quelque chose à éviter. Cela étant dit, la fragilité d'un test est souvent quelque chose qui n'est pas sous le contrôle d'une équipe. Voici ma situation;

J'utilise Cucumber, Nightwatch, Selenium et Browserstack pour exécuter des tests de bout en bout sur une application Web. Souvent, un scénario échouera en raison de la faiblesse inhérente de Selenium, de Browserstack ou du navigateur dans lequel je teste. Les interactions impliquant des mouvements de souris sont notoires pour cela. Il est rare que je puisse parcourir tous mes scénarios sans qu'au moins une poignée ne soit floconneuse.

Je ne peux pas rendre Selenium, Browserstack ou les navigateurs moins floconneux, c'est juste la nature des outils avec lesquels je dois travailler. La solution dont j'ai besoin est de pouvoir réessayer mes scénarios plusieurs fois s'ils échouent.

Je pense que nous devrions reconsidérer cela. Cucumber-Ruby l'a maintenant.

D'accord. Voici le code pour l'implémentation Ruby. Pourrait être utile pour une implémentation JS. https://github.com/cucumber/cucumber-ruby/pull/920/files

Salut tout le monde, la fonctionnalité « réessayer » est-elle maintenant disponible dans Cucumber-JS ? Autant je suis d'accord que les tests floconneux doivent être corrigés, les expériences montrent que ce n'est pas toujours possible lorsque l'on travaille dans de grands projets avec de nombreuses dépendances externes impliquées.
En fin de compte, si un cas de test aussi floconneux ne pouvait pas être couvert par l'automatisation en raison de l'absence de logique de réessai, il devrait de toute façon être testé manuellement.
Je pense que l'utilisation de la logique de nouvelle tentative devrait être laissée au choix de l'utilisateur de concombre.
Je suis conscient de la fonctionnalité de « réexécution », mais son utilisation ajoute une complexité supplémentaire, car les tests doivent être réexécutés séparément en face pour que le coureur Cucumber le fasse de manière transparente pour vous.

Salut @charlierudolph et @aslakhellesoy. Des progrès avec cette fonctionnalité ?

Personne n'y travaille à ma connaissance. Si quelqu'un fournit une pull request, j'envisagerais de l'ajouter.

Salut @aslakhellesoy merci d'avoir répondu si rapidement. C'est quelque chose dont nous avons vraiment besoin en ce moment car l'un des appareils que nous devons automatiser est un peu instable et dans un tel cas, il n'y a pas d'alternative vraiment pratique à la simple réexécution d'un scénario ayant échoué.
Mon idée est d'utiliser une balise par scénario pour spécifier le nombre de tentatives, mais au moins comme implémentation de départ qui pourrait être simplement un paramètre de ligne de commande.
Je vais essayer de jeter un oeil au code dans les prochains jours.

Ce serait génial! Veuillez essayer de le faire se comporter de la même manière que dans Cucumber-Ruby. S'il s'écarte de cela, nous ne pouvons pas le fusionner, car la consolidation/la cohérence est quelque chose que nous recherchons.

Salut @aslakhellesoy , J'ai implémenté la fonctionnalité de réessai de base en tant qu'option CLI --retry. Je l'ai testé au travail avec notre projet et cela fonctionne bien. J'aurais besoin d'autorisations pour pousser ma branche de travail et ouvrir un PR pour discuter de la mise en œuvre. Faites-moi savoir, merci.

@hurrikam Excellent travail.. 👏👏👏
Je suis également impatient de l'utiliser. J'utilise nightwatch-concombre et ils attendent que cela soit corrigé dans le concombre js. Réf # https://github.com/mucsi96/nightwatch-cucumber/issues/213

@charlierudolph pourriez-vous m'aider s'il vous plaît ? Je ne peux pas soumettre mon PR pour le moment.

@hurrikam, vous pouvez créer un fork et y envoyer votre code, puis soumettre un PR de votre fork dans ce référentiel. https://help.github.com/articles/fork-a-repo/

@charlierudolph s'il vous plaît voir PR-1114
Comme mentionné dans le titre, il s'agit de l'implémentation minimaliste (très peu de modifications de code en effet) pour faire fonctionner la fonctionnalité sans casser les formateurs et les rapports existants.

J'ai parcouru de vieilles conversations dans le référentiel Cucumber Ruby pour savoir si chaque exécution d'un test floconneux doit être signalée, en introduisant éventuellement un statut de résultat « floconneux » pour les exécutions précédentes. Je ne sais pas si cela a été fait et encore une fois, l'inconvénient serait d'obtenir toutes les tentatives du même cas de test dans les journaux.

Discutons-en.

@hurrikam mon équipe a pris une fourchette des relations publiques afin que nous puissions obtenir cette fonctionnalité. Cela fonctionne très bien jusqu'à présent. J'espère que vous pourrez le fusionner bientôt car le drapeau est d'une grande aide !

@Nick-Lucas C'est génial - Avez-vous cela dedans ?

@thomaswmanion oui, nous utilisons activement la fonctionnalité. Nous avons un backend qui peut parfois être un peu encombré par les files d'attente de tâches, donc c'est une bouée de sauvetage.

Pour tous ceux qui souhaitent utiliser le PR, vous pouvez pointer votre package.json sur ma fourchette (ou me la débrancher):

  "dependencies": {
    "cucumber": "https://github.com/Nick-Lucas/cucumber-js.git#feature/issue-727-retry",
  },

Le concombre est pré-construit, il peut donc être simplement installé dans node_modules. Il va sans dire qu'il n'y a certainement aucune garantie ou support car la fonctionnalité n'est même pas encore pré-alpha

ÉDITER:

J'ai maintenant quitté mon entreprise et remis le fork à leur github : https://github.com/wonderbill/cucumber-js.git#feature/issue -727-retry

Joli!!!! Merci @Nick-Lucas - appréciez la compréhension que les environnements des systèmes peuvent être de nature floconneuse !

Cela doit être fusionné dans Master, ce n'est pas fermé.

@thomaswmanion oui, nous utilisons activement la fonctionnalité. Nous avons un backend qui peut parfois être un peu encombré par les files d'attente de tâches, donc c'est une bouée de sauvetage.

Pour tous ceux qui souhaitent utiliser le PR, vous pouvez pointer votre package.json sur ma fourchette (ou me la débrancher):

  "dependencies": {
    "cucumber": "https://github.com/Nick-Lucas/cucumber-js.git#feature/issue-727-retry",
  },

Le concombre est pré-construit, il peut donc être simplement installé dans node_modules. Il va sans dire qu'il n'y a _certainement aucune garantie ni assistance_ car la fonctionnalité n'est même pas encore pré-alpha

ÉDITER:

J'ai maintenant quitté mon entreprise et remis le fork à leur github : https://github.com/wonderbill/cucumber-js.git#feature/issue -727-retry

Comment puis-je exécuter la fonctionnalité de nouvelle tentative lors de l'exécution de tests ?

@ricardgarcia utilise simplement l' --retry voir https://github.com/owncloud/phoenix/pull/1207/files
Nous utilisons la branche de mon PR ici https://github.com/cucumber/cucumber-js/pull/1205 jusqu'à ce qu'elle soit fusionnée, espérons-le un jour

Salut @individual-it , merci beaucoup pour la réponse. Cela devrait-il fonctionner si j'utilise webdriverIO pour exécuter mes tests sur cucumber-js ?
J'ai essayé la commande "--retry 1" mais aucune nouvelle tentative n'est en cours.

@ricardgarcia Comme décrit dans https://github.com/cucumber/cucumber-js/pull/1205 , pour utiliser cette fonction, vous pouvez utiliser

"cucumber": "cucumber/cucumber-js#issue-727-retry"

car les modifications ne sont pas encore fusionnées dans le repo principal de concombre.

Oui @jain-neeeraj J'ai utilisé cette version dans le package.json et cela n'a pas fonctionné, mais comme je l'ai mentionné, j'exécute des tests avec du concombre sur webdriverIO, donc le framework suivant "wdio-cucumber-framework". Cela devrait-il fonctionner d'une manière ou d'une autre ? Comment exécuter les tests afin de réessayer si j'utilise le framework cucumber-js ?

@ricardgarcia permet de collaborer à gitter https://gitter.im/cucumber/cucumber-js , je devrais pouvoir vous aider à résoudre ce problème.

@charlierudolph une chance que cela puisse être fusionné dans le maître?