Protractor: L'explorateur d'éléments ne fonctionne pas sur le nœud 8

Je ne pense pas que nous testions actuellement contre le nœud 8, il est donc logique que cela puisse être cassé. Merci d'avoir soulevé cela !

J'essaierai de creuser cela dans les prochains jours mais un RP pour résoudre ce problème serait le bienvenu !

_debugger et le débogueur CLI hérité ont été supprimés dans le nœud 8 : https://github.com/nodejs/node/commit/90476ac6ee

Des mises à jour à ce sujet ?

Pourrions-nous savoir quels sont les plans pour la prise en charge de Node 8 ? :)

Avec Node v8 prêt à entrer dans LTS en octobre, peut-être pourrions-nous obtenir une mise à jour ?

https://github.com/nodejs/LTS#lts -schedule1

Selon https://nodejs.org/en/docs/guides/debugging-getting-started/#legacy -debugger ,
l'équipe node.js migre les utilisateurs vers la nouvelle API inspect.

L'équipe envisage-t-elle de remettre cela en marche avec l'API inspect ou une autre approche ?

Même erreur https://github.com/node-inspector/node-inspector/issues/1025#issuecomment -339202842
4 mois déjà

Aussi https://stackoverflow.com/questions/44662442/node-inspector-not-starting

J'ai commencé à me pencher là-dessus. Voici quelques suppositions sur la façon dont la mise à jour pourrait fonctionner :

Pour autant que je sache, les changements doivent se produire dans debuggerCommons.js

Plutôt que require('_debugger'); il doit utiliser require('inspector'); ( docs here ). Vous pouvez ensuite ouvrir l'inspecteur, créer une session, vous y connecter, puis utiliser session.post et le protocole Chrome DevTools pour envoyer les messages afin d'ajouter les points d'arrêt.

J'aurai un crack à un PR quand j'aurai un peu de temps.

@phenomnomnominal Hé c'est super ! Puis-je savoir quand vous êtes disponible pour faire le PR ? Étant donné que cette fonctionnalité est si utile, ce serait formidable si elle pouvait être créée bientôt. Cela accélérera tellement notre développement.
Merci!

@phenomnomnominal Bonjour, nous prévoyons de prendre en charge le nœud 8.0 récemment, quel est votre plan actuel pour résoudre ce problème ?

Seulement ce que j'ai décrit ci-dessus. J'avais prévu de m'y essayer ce soir.

@phenomnomnominal c'est super, merci beaucoup !

@phenomnomnominal Salut, des mises à jour jusqu'à présent ?

J'ai commencé à essayer, mais j'avais des problèmes avec Selenium lorsque j'essayais d'exécuter les tests (des conseils ?). Je vais avoir plus de temps mardi soir. La nouvelle API est assez différente, mais je ne prévois pas de problèmes réels.

OK merci beaucoup. Je suis censé avoir un peu de temps après lundi, peut-être que je pourrai aussi m'en occuper après ça.

J'ai... quelque part ? Il s'avère que le débogage du débogueur n'est pas aussi simple que je l'aurais espéré. @qiyigg avez-vous eu l'occasion de regarder quoi que ce soit ?

Je vais regarder ça aujourd'hui, merci !

J'aurai un peu plus de temps ce soir aussi, nous pourrons comparer les notes plus tard.

Salut, des progrès sur ce problème la semaine dernière? Cela se produit toujours.

Pour le débogueur/explorateur de rapporteur, nous avons décidé de ne pas le prendre en charge dans le nœud 8.

1. Débogueur/explorateur de rapporteur principalement conçu pour déboguer les tests dans le flux de contrôle ; mais le flux de contrôle est quelque chose que nous n'encourageons pas (en particulier nous avons async/wait natif dans le nœud 8) et sera finalement obsolète.
2. Après enquête, nous avons constaté que cela pourrait nécessiter beaucoup d'efforts pour le réparer et que cela ne valait pas la peine de le faire selon la raison 1.
3. Nous travaillons sur la fourniture de nouveaux documents de débogage pour le nœud 8 à l'aide de l'outil natif d'inspection async/await et chrome, qui offrira une meilleure expérience que le débogueur d'origine.
4. @phenomnomnominal Si vous avez une percée à ce sujet, nous aimerions l'examiner. Merci pour votre effort.

Avez-vous une sorte d'ETA pour cela? Nous sommes en train de ronger son frein là où je travaille. J'essaie d'enseigner à certaines personnes les tests e2e et nous n'avons aucun moyen d'entrer en mode débogage et d'exécuter réellement du code dans le contexte où l'échec se produit. S'il existe un moyen de le faire en dehors de cela, faites-le moi savoir.

@KellyR-STCU
Salut,
Pour la version de nœud < 8, vous pouvez utiliser le processus/les outils de débogage d'origine.
Pour la version de nœud >=8, vous pouvez suivre le nouveau processus de débogage, qui utilise Node.js async/await natif pour gérer les appels asynchrones (afin que nous n'ayons pas besoin de compter sur le flux de contrôle et l'ancien débogueur), et utilisez l'inspecteur chrome ( ou tout autre débogueur de nœud) pour déboguer

Nous avons quelques documents pour décrire comment déboguer avec l'inspecteur natif async/await et chrome
débogage avec flux de contrôle désactivé
comment utiliser async/attendre

J'espère que ça aide

@qiyigg et elementExplorer ?

@monkpit, cela ne fonctionnera pas dans le nœud 8 pour la même raison. Nous n'avons pas de substitut complet à cela, mais vous pouvez ouvrir et utiliser l'outil de développement Chrome pendant le débogage, cela n'entrera pas en conflit avec le débogage du rapporteur comme nous l'avons rencontré auparavant.

@qiyigg ok, puisque la fonctionnalité elementExplorer était au centre du problème, je vais la laisser ouverte.

La solution est également un peu un problème car elle nécessite de réécrire les tests existants car "vous ne pouvez pas utiliser un mélange d'async/wait et du flux de contrôle". Ce serait bien si vous pouviez spécifier l'approche à adopter par test afin que le changement ne nécessite pas la mise à jour de tous les tests existants.

@uriah-ascend
oui, je dois admettre que ce n'est pas une solution parfaite. Mais comme je l'ai mentionné ci-dessus, le flux de contrôle est quelque chose qui sera finalement supprimé . Convertir nos tests en async/wait est quelque chose que nous devrions faire progressivement, et cela nous donne une meilleure expérience de débogage.
Je suppose qu'une façon de faire est d'avoir une configuration de test distincte pour les nouveaux tests, puis de les convertir progressivement.

@qiyigg existe-t-il un guide ou une documentation sur la façon de convertir en async/wait ?

De très bonnes informations dans ces deux liens qu'il a fournis intitulés débogage avec flux de contrôle désactivé et
comment utiliser async/attendre

Le second est probablement plus une étape par étape pour la conversion.

Après avoir eu un problème avec browser.pause() sur le nœud 8.

J'ai suivi Disabled Control Flow .

Au lieu d'exécuter node --inspect-brk bin/protractor <config_file> et de déboguer dans le navigateur, j'utilise node inspect $(which protractor) <config_file> suivi de debug> cont dans le terminal.

Maintenant, j'ai l'équivalent de browser.pause() .

c'est-à-dire utiliser debugger à la place de browser.pause()

Juste pour vérifier : nous avons une grande base de code de rapporteur, qui ne peut pas être convertie en async/wait d'un seul coup. Une bonne façon de procéder consiste d'abord à convertir toutes les actions de rapporteur "async" en utilisant le chaînage de promesses, n'est-ce pas ? De cette façon, les choses devraient fonctionner, que le flux de contrôle soit activé ou non.
Merci !

Le chaînage de promesse fonctionnera, que le flux de contrôle soit activé ou non, mais il est parfois un peu désordonné et vous voudrez peut-être le redéfinir en async/attendre un jour ?
Ma suggestion est donc d'avoir deux config distinctes pour l'instant, de mettre le nouveau test/test converti dans la nouvelle config qui désactive control_flow et de se débarrasser progressivement de l'ancien

Le problème est que nous partageons beaucoup de fonctions entre les tests, donc si nous migrons ces fonctions vers async wait, nous casserons tous les tests qui les utilisent et qui n'ont pas été migrés vers async wait (indice : BEAUCOUP). Et si on garde deux versions d'une même fonction on risque de les voir diverger.
Il me semble donc que soit nous déplaçons tout pour promettre le chaînage comme étape intermédiaire avant de passer à async/await, soit nous configurons babel pour transpiler notre base de code de test (en utilisant quelque chose comme ça : https://stackoverflow.com/questions/ 28708975/transpile-async-await-proposal-with-babel-js ?), afin que nous puissions écrire async/await et le transpiler en quelque chose qui peut être exécuté avec ou sans contrôle de flux.
Est-ce que quelqu'un sait si cela a déjà été fait ?
Dans tous les cas, il semble que ce serait une bonne idée de donner les chemins de migration pour les grosses bases de code sur le readme...

Cela a du sens, en fait, nous y pensons récemment.
J'ai parlé à une équipe interne qui a migré une grande base de code vers async/wait.
Ils ont découvert que cela introduirait des bugs subtils et des conditions de concurrence s'ils changeaient les utilitaires communs pour promettre la chaîne et ils ont déjà renoncé à le faire.
Ils ont copié certains utilitaires courants et les ont traduits en async/wait. Je ne sais pas si c'est la meilleure solution, mais comme vous l'avez mentionné, il y aura un risque de divergence
Nous travaillons également sur l'écriture d'un outil de migration pour le rendre plus facile, mais les outils ne fonctionneront peut-être pas en externe.

Quoi qu'il en soit, nous travaillons récemment sur un plan de migration et devrions donner des conseils de migration quelque part dans un proche avenir.

Merci pour votre réponse, c'est bon de savoir que c'est un problème qui est
en cours d'examen !
Je pense que ce serait une bonne idée de créer un problème spécifique sur la façon de
migrer des bases de code volumineuses, afin que les gens voient qu'il est en train d'être travaillé.

Le 16 janv. 2018 19:58, "qiyi" [email protected] un écrit :

Cela a du sens, en fait, nous y pensons récemment.
J'ai parlé à une équipe interne qui a migré une grande base de code vers
async/attendre.
Ils ont découvert que cela introduirait des bugs subtils et des conditions de course s'ils
changé les utilitaires communs pour promettre la chaîne et ils ont déjà renoncé à le faire.
Ils ont copié certains utilitaires courants et les ont traduits en async/wait. je
ne sais pas si c'est la meilleure solution, mais comme vous l'avez mentionné, ce sera
avoir des risques divergents
Nous travaillons également sur l'écriture d'un outil de migration pour le rendre plus facile, mais
les outils ne fonctionneront peut-être pas à l'extérieur.

Quoi qu'il en soit, nous travaillons sur un plan de migration récemment, et devrions donner quelques
conseils de migration quelque part dans un proche avenir.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/angular/protractor/issues/4307#issuecomment-358068096 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AHHOgiLEdFS-xZVcOKmO1EB-CID53cryks5tLPFagaJpZM4NtM1n
.

Salut les gars! Existe-t-il une solution de contournement ?

protractor - 5.2.2
nodejs - 9.3

protractor --elementExplorer
(node:72438) [DEP0022] DeprecationWarning: os.tmpDir() is deprecated. Use os.tmpdir() instead.
[19:15:43] I/local - Starting selenium standalone server...
[19:15:44] I/local - Selenium standalone server started at http://172.29.148.101:58279/wd/hub
[19:15:45] I/protractor -
[19:15:45] I/protractor - ------- Element Explorer -------
[19:15:45] I/protractor - Starting WebDriver debugger in a child process. Element Explorer is still beta, please report issues at github.com/angular/protractor
[19:15:45] I/protractor -
[19:15:45] I/protractor - Type <tab> to see a list of locator strategies.
[19:15:45] I/protractor - Use the `list` helper function to find elements by strategy:
[19:15:45] I/protractor -   e.g., list(by.binding('')) gets all bindings.
[19:15:45] I/protractor -
module.js:557
    throw err;
    ^

Error: Cannot find module '_debugger'
    at Function.Module._resolveFilename (module.js:555:15)
    at Function.Module._load (module.js:482:25)
    at Module.require (module.js:604:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/usr/local/lib/node_modules/protractor/built/debugger/debuggerCommons.js:1:82)
    at Module._compile (module.js:660:30)
    at Object.Module._extensions..js (module.js:671:10)
    at Module.load (module.js:573:32)
    at tryModuleLoad (module.js:513:12)
    at Function.Module._load (module.js:505:3)
[19:15:45] I/local - Shutting down selenium standalone server.
MB-219751:~ olekh$ 

Connaissant également le Error: Cannot find module '_debugger' , OSX.

Cette question est ouverte depuis près d'un an. Toujours pas de progrès ?

@ajklotz Je peux confirmer que cela ne fonctionne toujours qu'avec Node 7. J'utilise nvm pour basculer entre les versions de Node afin d'utiliser l'explorateur d'éléments. C'est pénible, mais ça marche !

@ajklotz @monkpit @mraible Si vous pouvez exécuter avec Node 8 ou supérieur, je vous recommande d'essayer de faire ce qui suit :

1. Regardez cette vidéo "Protractor: A New Hope" https://youtu.be/6aPfHrSl0Qk?t=1051 , commençant spécifiquement vers 17:31
2. Passer à l'utilisation de Node 8 ou supérieur
3. Convertissez vos tests pour utiliser les mots clés async/await ES2017 : https://github.com/angular/protractor/blob/master/docs/async-await.md
4. Ajoutez SELENIUM_PROMISE_MANAGER: false, à votre protractor.conf.js
5. Utilisez la nouvelle fonction debugger et utilisez Chrome Inspector pour déboguer : https://github.com/angular/protractor/blob/master/docs/debugging.md#disabled -control-flow

J'ai fait cela avec mes propres tests de rapporteur et je confirme que cela fonctionne.

@ajklotz @monkpit @mraible Voici un exemple où j'ai converti les tests Protractor pour utiliser async/await : https://github.com/buildbot/buildbot/pull/4074/files

Tout ce qui renvoie une promesse, vous collez un await devant tel que :

• .click()
• .browser.wait()
• .browser.get()
• .getText()

Si une fonction a un appel à await , alors la signature de la fonction doit avoir async devant elle.

Si vous appelez une fonction avec async , alors vous devez la await .

Cela prend du temps, mais une fois que vous l'avez fait, cela fonctionne.

@rodrigc Ma zone de tests utilisant déjà async/await, le problème est qu'à partir de la ligne de commande, protractor --elementExplorer ne fonctionne que si vous utilisez le nœud 7.

FWIW, il semble qu'une fonctionnalité de langage comme async/await ne devrait de toute façon pas être pertinente. Peut-être qu'un échange en tant que solution provisoire a du sens, mais Protractor n'implique pas une dépendance à ce style.

@monkpit Oui, vous avez tout à fait raison. La cause première de votre problème est que sur cette ligne : https://github.com/angular/protractor/blob/master/lib/debugger/debuggerCommons.js#L1 , le module _debugger est importé, ce qui n'est pas disponible sur node8. Tout ce qui utilise debuggerCommons.js ne fonctionnera donc pas sur node8, y compris elementExplorer .

Donc, si vous souhaitez utiliser node8 ou supérieur et déboguer avec un rapporteur, la clé est d'utiliser async/await et de suivre les étapes sur : https://github.com/angular/protractor/blob/master/docs/ débogage.md

Les anciens trucs de débogage ne fonctionneront pas.

Soit il ne sera pas corrigé (c'est bien, je peux utiliser la solution de contournement), soit il sera mis à jour pour utiliser le nœud 8+ (c'est aussi bien). Mais j'adorerais voir une réponse officielle dans un sens ou dans l'autre.

@monkpit

Je pense que la réponse se trouve dans ce commentaire de @qiyigg.

Pour le débogueur/explorateur de rapporteur, nous avons décidé de ne pas le prendre en charge dans le nœud 8...

D'après ce que j'ai entendu de @qiyigg quand je lui ai parlé, l'objectif actuel de l'équipe est de _désactiver le flux de contrôle dans les tests Protractor_.

Je vais clore ce sujet pour le moment. C'est encore ouvert à la discussion.

@qiyigg J'ai commencé à utiliser le nouveau debugger avec Chrome Inspector et node8 et cela fonctionne bien.

L'équipe de rapporteurs peut-elle commencer à marquer la documentation de l'ancien code de débogage qui utilise debuggerCommon.js comme OBLIGATOIRE ? Je suis d'accord avec @monkpit que les choses sont un peu déroutantes maintenant où le code ne fonctionne pas avec node8, mais il n'est pas marqué comme obsolète. En fin de compte, cet ancien code de débogage devrait simplement être supprimé s'il ne sera jamais corrigé avec node8.

Si vous jetez un œil au document de débogage, nous avons déjà mentionné que le débogueur ne fonctionnera pas sur Node 8
https://github.com/angular/protractor/blob/master/docs/debugging.md#enabled-control-flow
"Remarque : Le débogueur de rapporteur et l'explorateur d'éléments ne peuvent pas être utilisés pour Node.js 8+"

Une chose à garder à l'esprit est que tout le monde n'utilise pas Node 8+, nous ne pouvons pas dire que le débogueur est obsolète et obliger tout le monde à utiliser async/wait (bien que nous le fassions dans Google).

Apparemment, le passage à Node 8+ et async/await présente de nombreux avantages et nous devrions éventuellement y passer, mais ce n'est pas une tâche facile car nous devons modifier beaucoup de notre code existant. Nous travaillons sur cela à l'intérieur de Google et essayons d'accumuler plus d'expérience sur la migration (même les outils de migration) et espérons que cela pourra également aider les utilisateurs en dehors de Google à terme.

Je pense que ce que nous pourrions faire maintenant, c'est rendre cette erreur plus claire, par exemple, lancer une exception : l'explorateur/débogueur d'éléments n'est pas pris en charge pour le nœud 8+ au lieu de "Erreur : Impossible de trouver le module '_debugger'", Un PR sera très accueilli.

@qiyigg Je suggérerais de mettre cet avertissement en gras et en MAJUSCULES . C'est un peu difficile à saisir sur cette page, car il y a beaucoup de mots.

Je suis vraiment content du nouveau débogueur car je peux utiliser intellij pour exécuter mes tests. c'est bien mieux que l'explorateur d'éléments (que j'ai plutôt aimé) mais utiliser mon IDE pour déboguer les tests est une énorme victoire.

@qiyigg Je travaille dans une entreprise qui fabrique des imprimantes de grande production. Parce que nous avons changé toutes nos interfaces utilisateur pour utiliser Angular (hourra!), Nous avons décidé d'utiliser Protractor pour les tests UI E2E (également hourra). En dehors de ces tests E2E, nous avons également de vrais tests de bout en bout qui fonctionnent sur un système en cours d'exécution. Tous les cas de test pour ce système de test sont spécifiés dans le framework de test Microsft TFS et nous utilisons un DSL pour les écrire. Ce DSL charge les objets de page que nous avons écrits pour nos interfaces utilisateur via un rapporteur démarré de manière interactive (donc l'explorateur d'éléments) et appelle des méthodes sur eux pour exécuter ses tests.

Jusqu'ici tout va bien, diriez-vous, nous avons des milliers de ces tests et ils fonctionnent vraiment "en tant qu'utilisateur". Ce que je fais de cette conversation, c'est que l'explorateur d'éléments est supprimé avec le nouveau nœud (et le nouveau nœud est obligatoire pour la mise à niveau d'Angular). Cela signifie également que tout d'un coup, toute notre base de test cesserait de fonctionner.

J'obtiens le changement avec async / wait et nous réécrirons évidemment nos objets de page pour le prendre en charge, mais il n'y a pas vraiment d'alternative pour insérer à distance des commandes de rapporteur, n'est-ce pas ? Je devrai toujours passer "un test" qui n'appelle que "debugger", puis communiquer directement avec chrome pour appeler une commande sur mes objets de page, puis passer au prochain appel "debugger" que je devrai alors probablement exécuter dans une boucle while.

Des scénarios comme ceux-ci n'étaient-ils pas pris en charge ? Ne le seront-ils pas ? Ou est-ce que je manque juste quelque chose... Pour moi, le débogage des erreurs dans vos tests/code est totalement différent de l'instruction à distance de commandes de test. Ce dernier est quelque chose que l'explorateur d'éléments a utilisé pour faciliter :)

Pour au moins partager ma solution actuelle, j'ai écrit ce test, qui est le seul test système que j'exécute avec le rapporteur (CompletableFuture est une classe d'aide évidemment):

jasmine.DEFAULT_TIMEOUT_INTERVAL = 3600000; // arbitrary large timeout
(global as any).systemTestsDone = new CompletablePromise<void>();

describe('TestHelper', () => {
  it('should provide a way to interactively run tests', async () => {
    await (global as any).systemTestsDone;
  });
});

node --inspect .\node_modules\protractor\bin\protractor .\systemTests\protractor.conf.js

Ce test continue ensuite de s'exécuter pendant que je connecte mon client WS (C#) qui sert de pont entre les spécifications du test et les objets de la page. Ce pont demande ensuite au navigateur de charger les objets de la page et les tests commencent à s'exécuter.

La dernière commande que j'envoie au navigateur est bien sûr

global.systemTestsDone.complete()

afin que le test se termine normalement. Je ne pense pas que ce soit vraiment horrible, la seule chose étrange est que je dois maintenant abuser d'un test pour entrer dans un mode interactif. Si davantage de personnes manquent de fonctionnalités comme celle-ci, il peut être judicieux de les inclure à nouveau dans le rapporteur. Je ne parle pas d'un protocole devtools entier, mais de la possibilité de laisser le rapporteur en cours d'exécution pendant que vous, par exemple, utilisez la console de chrome ou le code Visual Studio comme "explorateur d'éléments".

ajouter @vikerman , qui prendra en charge les affaires de rapporteur.

@vikerman Dois-je faire une demande de fonctionnalité à partir des commentaires ci-dessus ?

En bref, ce que j'aimerais avoir dans le rapporteur (puisque --elementExplorer ne fonctionne plus avec les versions récentes de node.js) est un mode qui démarre simplement le rapporteur, ignore les fichiers de spécifications et continue de fonctionner jusqu'à ce qu'un appel de méthode manuel (quelque chose comme protractor.exit() ?). Nous pourrions démarrer le rapporteur dans ce mode avec node --inspect , charger des objets de page et connecter un lanceur de test externe au protocole du débogueur et exécuter les tests de manière interactive.

ce serait vraiment bien si quelqu'un répare cela. J'utilise actuellement nvm comme solution de contournement.
J'utilise nvm pour installer le nœud 7.10.1 et lancer elementExplorer à partir de là.
solution de contournement un peu boiteuse mais cela fonctionne pour l'instant

Je suis passé au nœud v6 pour que cela fonctionne et maintenant je ne peux pas exécuter mon application Angular 6 car le nœud 6 n'est pas pris en charge dans Angular 6+. Il semble qu'Angular cible désormais le nœud >= 8.9.0.

Existe-t-il un bon travail que je peux suivre pour obtenir un rapporteur REPL sans avoir à exécuter deux versions de nœud?

J'ai la même erreur dans la console. Je suis les instructions données ici
https://github.com/angular/protractor/blob/master/docs/debugging.md#enabled-control-flow

mais toujours la même erreur arrive

Alors est-ce la fin pour browser.pause() / browser.debugger() ? Il semble que nous devrions nous éloigner du flux de contrôle et utiliser le débogueur de nœud.
https://github.com/angular/protractor/blob/master/docs/debugging.md

L'utilisation de NVM pour passer à la version de nœud 7.10.1 a résolu le problème de browser.pause() pour moi.

Je comprends que async/wait est la voie à suivre, et utiliser Webstorm pour déboguer des tests avec des points d'arrêt est absolument transparent, mais là où je pense que l'absence d'elementExplorer est son utilisation étendue dans le package elementor , qui était un moyen agréable de tester de manière interactive des pièces de code à la volée (dans l'omnibox) au lieu d'exécuter l'intégralité du test à partir de zéro.
Avec le processus de débogage donné pour nodejs 8+, les commandes de la console ne résolvent pas les promesses pendant que l'inspecteur est suspendu à un point d'arrêt, ce qui, je le réalise, est contre-intuitif, mais tout cela a entraîné une augmentation subtile du temps passé à écrire/ tests de débogage et perte d'une fonctionnalité largement utilisée (en fonction du nombre de réponses sur ce fil).
Existe-t-il des plans pour remplacer l'ancienne fonctionnalité elementExplorer dans le rapporteur ?

@ woppa684 La suggestion fonctionne bien pour moi. Merci @ woppa684. Je viens de passer au nœud 10+ qui a repl-wait (vous pouvez donc simplement attendre dans la console)

J'ai ajouté tous mes fichiers de configuration pour référence, j'espère que cela aidera quelqu'un :

Spécification spéciale de débogage interactif - interactive.e2e.ts

import { LoginPage } from './src/pages/login.po';
import { AppPage } from './src/pages/app.po';
import { SwitchProfileSideSheet } from './src/side-sheets/switch-profile-side-sheet.po';
import { sel } from '../src/testing/get-component';

const login = new LoginPage();
const app = new AppPage();
const switchProfileSideSheet = new SwitchProfileSideSheet();

// add my own page objects to the global object so I can use them interactively.
global['sel'] = sel;
global['po'] = {
  login,
  app,
  switchProfileSideSheet,
};

(global as any).systemTestsDone = new Promise(function(_resolve, _reject) {
  global['finishInteractiveDebug'] = _resolve;
});

describe('TestHelper', () => {
  it('should provide a way to interactively run tests', async () => {
    await (global as any).systemTestsDone;
  });
});

package.json

    "e2e-interactive": "node --experimental-repl-await --inspect-brk ./node_modules/.bin/protractor ./e2e/protractor.interactive.conf",

rapporteur.interactive.conf.js

// Protractor configuration file, see link for more information
// https://github.com/angular/protractor/blob/master/lib/config.ts

// standard protractor config
const baseConfig = require('./protractor.conf');
const configCopy = Object.assign({}, baseConfig.config);

const oneDayInMilliSeconds = 1000 * 60 * 60 * 24;
// set timeout to a huge number
// so it's not an issue when we pause in the debugger
configCopy.allScriptsTimeout = oneDayInMilliSeconds;
configCopy.jasmineNodeOpts.defaultTimeoutInterval = oneDayInMilliSeconds;
// just load our interactive specs
configCopy.specs = ['./interactive.e2e.ts'];

console.log('interactive config', configCopy);
exports.config = configCopy;

J'utilise browser.sleep(100000) au lieu de browser.pause()