Protractor: El explorador de elementos no funciona en el nodo 8

No creo que estemos probando actualmente contra el nodo 8, por lo que tiene sentido que esto pueda estar roto. ¡Gracias por mencionar este tema!

Intentaré profundizar en esto en los próximos días, ¡pero un PR para solucionarlo sería muy bienvenido!

_debugger y el depurador CLI heredado se eliminaron en el nodo 8: https://github.com/nodejs/node/commit/90476ac6ee

¿Alguna actualización sobre esto?

¿Podríamos saber cuáles son los planes para el soporte de Node 8? :)

Con Node v8 configurado para ingresar a LTS en octubre, ¿tal vez podríamos obtener una actualización?

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

Según https://nodejs.org/en/docs/guides/debugging-getting-started/#legacy -debugger,
el equipo de node.js está migrando usuarios a la nueva API de inspección.

¿Hay planes del equipo para que esto vuelva a funcionar con la API de inspección o con algún otro enfoque?

Mismo error https://github.com/node-inspector/node-inspector/issues/1025#issuecomment -339202842
4 meses ya

También https://stackoverflow.com/questions/44662442/node-inspector-not-starting

Empecé a echar un vistazo a esto. Aquí hay un montón de conjeturas sobre cómo podría funcionar la actualización:

Por lo que puedo decir, los cambios deben ocurrir en debuggerCommons.js

En lugar de require('_debugger'); , necesita usar require('inspector'); ( docs aquí ). Luego puede abrir el inspector, crear una sesión, conectarse a él y luego usar session.post y el Protocolo de DevTools de Chrome para enviar los mensajes para agregar los puntos de interrupción.

Tendré una oportunidad en un PR cuando tenga algo de tiempo.

@phenomnomnominal ¡Oye, eso es genial! ¿Puedo saber cuándo estás disponible para hacer las relaciones públicas? Dado que esta funcionalidad es tan útil, sería genial si se pudiera crear pronto. Acelerará mucho nuestro desarrollo.
¡Gracias!

@phenomnomnominal Hola, estamos planeando admitir el nodo 8.0 recientemente, ¿cuál es su plan actual para solucionar este problema?

Solo lo que describí anteriormente. Estaba pensando en intentarlo esta noche.

@phenomnomnominal eso es genial, ¡muchas gracias!

@phenomnomnominal Hola, ¿alguna actualización hasta ahora?

Empecé a intentarlo, pero tenía problemas con Selenium al intentar ejecutar las pruebas (¿algún consejo?). Voy a tener más tiempo el martes por la noche. La nueva API es bastante diferente, pero no preveo ningún problema real.

OK muchas gracias. Se supone que tendré algo de tiempo después del lunes, tal vez también pueda investigarlo después de eso.

Tengo ... en alguna parte? Resulta que depurar el depurador no es tan sencillo como esperaba. @qiyigg, ¿tuviste la oportunidad de mirar algo?

Lo investigaré hoy, ¡gracias!

También tendré más tiempo esta noche, podemos comparar notas más tarde.

Hola, ¿algún progreso en este tema en la última semana? Todavía está ocurriendo.

Para el depurador / explorador de transportador, decidimos no admitirlo en el nodo 8.

1. Depurador / explorador de transportador diseñado principalmente para depurar pruebas en el flujo de control; pero el flujo de control es algo que no fomentamos (especialmente tenemos async / await nativo en el nodo 8) y eventualmente quedará obsoleto.
2. Después de investigar, descubrimos que podría necesitar mucho esfuerzo para solucionarlo y no vale la pena hacerlo de acuerdo con la razón 1.
3. Estamos trabajando para proporcionar nuevos documentos de depuración para el nodo 8 utilizando la herramienta nativa async / await y chrome inspector, que brindará una mejor experiencia que el depurador original.
4. @phenomnomnominal Si tiene algún avance sobre esto, nos gustaría revisarlo. Gracias por tu esfuerzo.

¿Tiene algún tipo de ETA para esto? Estamos mordiendo un poco el lugar donde trabajo. Tratando de enseñar a algunas personas sobre las pruebas de e2e y no tenemos una forma de entrar en modo de depuración y ejecutar el código en el contexto donde ocurre la falla. Si hay alguna manera de hacer esto fuera de esto, hágamelo saber.

@ KellyR-STCU
Hola,
Para la versión de nodo <8, puede utilizar el proceso / herramientas de depuración originales.
Para la versión de nodo> = 8, puede seguir el nuevo proceso de depuración, que usa async / await nativo de Node.js para manejar llamadas asincrónicas (para que no necesitemos depender del flujo de control y el depurador antiguo), y usar el inspector de Chrome ( o cualquier otro depurador de nodos) para depurar

Tenemos algunos documentos para describir cómo depurar con async / await nativo y el inspector de Chrome
depuración con flujo de control deshabilitado
cómo usar async / await

Espero eso ayude

@qiyigg ¿qué pasa con elementExplorer?

@monkpit , no funcionará en el nodo 8 por la misma razón. No tenemos un sustituto completo para eso, pero puede abrir y usar la herramienta de desarrollo de Chrome durante la depuración, no entrará en conflicto con la depuración del transportador como vimos antes.

@qiyigg ok, dado que la función elementExplorer fue el foco del problema, la dejaré abierta.

La solución también es un poco problemática, ya que requiere reescribir las pruebas existentes porque "no se puede usar una combinación de async / await y el flujo de control". Sería bueno si pudiera especificar qué enfoque tomar por prueba para que el cambio no requiera actualizar todas las pruebas existentes.

@ uriah-ascend
sí, tengo que admitir que no es una solución perfecta. Pero como mencioné anteriormente, el flujo de control es algo que eventualmente se eliminará . Convertir nuestras pruebas a async / await es algo que deberíamos hacer gradualmente y nos brinda una mejor experiencia de depuración.
Supongo que una forma de hacerlo es tener una configuración de prueba separada para nuevas pruebas y luego convertirlas gradualmente.

@qiyigg, ¿hay alguna guía o documentación sobre cómo convertir a async / await?

Muy buena información en esos dos enlaces que proporcionó titulada depuración con el flujo de control deshabilitado y
cómo usar async / await

El segundo es probablemente más un paso a paso para la conversión.

Después de tener un problema con browser.pause() en el nodo 8.

Seguí el flujo de control para discapacitados .

En lugar de ejecutar node --inspect-brk bin/protractor <config_file> y depurar en el navegador, uso node inspect $(which protractor) <config_file> seguido de debug> cont en la terminal.

Ahora tengo el browser.pause() .

es decir, use debugger en lugar de browser.pause()

Solo para comprobarlo: tenemos una base de código de transportador grande, que no se puede convertir a async / await de una sola vez. Una buena forma de hacerlo es convertir primero todas las acciones de transportador "asíncronas" utilizando el encadenamiento de promesas, ¿verdad? De esta forma, las cosas deberían funcionar tanto si el flujo de control está habilitado como si no.
Gracias !

El encadenamiento de promesas funcionará independientemente de que el flujo de control esté habilitado o no, pero a veces es un poco complicado y es posible que desee volver a cambiarlo a async / await algún día.
Entonces, mi sugerencia es tener dos configuraciones separadas por ahora, poner la nueva prueba / prueba convertida en la nueva configuración que deshabilita control_flow y deshacerse de la anterior gradualmente

El problema es que compartimos muchas funciones entre las pruebas, por lo que si migramos estas funciones a async await, estaremos rompiendo todas las pruebas que las usan y que no se han migrado a async await (pista: MUCHO). Y si mantenemos dos versiones de la misma función corremos el riesgo de que diverjan.
Entonces me parece que movemos todo para prometer encadenamiento como un paso intermedio antes de pasar a async / await, o configuramos babel para transpilar nuestra base de código de prueba (usando algo como eso: https://stackoverflow.com/questions/ 28708975 / transpile-async-await-proposition-with-babel-js?), Para que podamos escribir async / await y hacer que se transpile a algo que se pueda ejecutar con flujo de control o sin él.
¿Alguien sabe si esto se ha hecho antes?
En cualquier caso, parece que sería una buena idea proporcionar rutas de migración para grandes bases de código en el archivo Léame ...

Tiene sentido, de hecho lo estamos pensando recientemente.
Hablé con un equipo interno que migró una gran base de código a async / await.
Descubrieron que introduciría errores sutiles y condiciones de carrera si cambiaban las utilidades comunes a la cadena de promesas y ya se dieron por vencidos para hacerlo.
Copiaron algunas utilidades comunes y las tradujeron a async / await. No sé si es la mejor solución, pero como mencionaste, tendrá algunos riesgos divergentes.
También estamos trabajando en la redacción de alguna herramienta de migración para que sea más fácil, pero es posible que las herramientas no funcionen externamente.

De todos modos, estamos trabajando en un plan de migración recientemente y deberíamos dar algunos consejos de migración en algún lugar en el futuro cercano.

Gracias por su respuesta, es bueno saber que se trata de un problema que
siendo examinado!
Creo que sería una buena idea crear un problema específico sobre cómo
migrar grandes bases de código, para que la gente vea que se está trabajando.

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

Tiene sentido, de hecho lo estamos pensando recientemente.
Hablé con un equipo interno que migró una gran base de código a
async / await.
Descubrieron que introduciría errores sutiles y condiciones de carrera si
cambiaron utilidades comunes a la cadena de promesas y ya se dieron por vencidos para hacer eso.
Copiaron algunas utilidades comunes y las tradujeron a async / await. I
No sé si es la mejor solución, pero como mencionaste, será
tiene algún riesgo divergente
También estamos trabajando en la redacción de alguna herramienta de migración para que sea más fácil, pero
las herramientas tal vez no funcionen externamente.

De todos modos, estamos trabajando en un plan de migración recientemente y deberíamos dar algunos
asesoramiento sobre migración en algún lugar en un futuro próximo.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/angular/protractor/issues/4307#issuecomment-358068096 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AHHOgiLEdFS-xZVcOKmO1EB-CID53cryks5tLPFagaJpZM4NtM1n
.

¡Hola tios! ¿Existe alguna solución?

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$ 

También experimenta el Error: Cannot find module '_debugger' , OSX.

Este tema ha estado abierto durante casi un año. ¿Todavía no hay progreso?

@ajklotz Puedo confirmar que todavía solo funciona con el Nodo 7. He estado usando nvm para cambiar entre versiones de Nodo para usar el explorador de elementos. Es un dolor, ¡pero funciona!

@ajklotz @monkpit @mraible Si puede ejecutar con el Nodo 8 o superior, le recomiendo que intente hacer lo siguiente:

1. Vea este video "Transportador: una nueva esperanza" https://youtu.be/6aPfHrSl0Qk?t=1051 , específicamente a partir de las 17:31
2. Cambiar para usar el Nodo 8 o superior
3. Convierta sus pruebas para usar las palabras clave async / await de ES2017: https://github.com/angular/protractor/blob/master/docs/async-await.md
4. Agregue SELENIUM_PROMISE_MANAGER: false, a su protractor.conf.js
5. Use la nueva función debugger y use el inspector de Chrome para depurar: https://github.com/angular/protractor/blob/master/docs/debugging.md#disabled -control-flow

He hecho esto con mis propias pruebas de transportador y confirmo que funciona.

@ajklotz @monkpit @mraible Aquí hay un ejemplo en el que convertí pruebas de transportador para usar async / await: https://github.com/buildbot/buildbot/pull/4074/files

Cualquier cosa que devuelva una Promesa, coloca un await delante de ella, como por ejemplo:

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

Si una función tiene una llamada a await , entonces la firma de la función debe tener async delante.

Si llama a una función con async , entonces debe await it.

Lleva un tiempo, pero una vez que lo haces, funciona.

@rodrigc Mi área de pruebas ya usa async / await, el punto de este problema es que desde la línea de comando, protractor --elementExplorer no funciona a menos que use el nodo 7.

FWIW, parece que una característica de lenguaje como async/await debería ser irrelevante de todos modos. Quizás un intercambio como solución temporal tenga sentido, pero Transportador no implica dependencia de ese estilo.

@monkpit Sí, tienes toda la razón. La causa raíz de su problema es que en esta línea: https://github.com/angular/protractor/blob/master/lib/debugger/debuggerCommons.js#L1 , se importa el módulo _debugger , que no está disponible en node8. Todo lo que use debuggerCommons.js no funcionará en el nodo8, incluido elementExplorer .

Entonces, si desea usar node8 o superior y depurar con transportador, la clave es usar async/await y seguir los pasos en: https://github.com/angular/protractor/blob/master/docs/ debugging.md

Las viejas cosas de depuración no funcionarán.

O no se solucionará (está bien, puedo usar la solución alternativa) o se actualizará para usar el nodo 8+ (eso también está bien). Pero me encantaría ver una respuesta oficial de una forma u otra.

@monkpit

Creo que la respuesta está en este comentario de @qiyigg.

Para el depurador / explorador de transportador, decidimos no admitirlo en el nodo 8 ...

Por lo que escuché de @qiyigg cuando hablé con él, el enfoque actual del equipo está en _deshabilitar el flujo de control en las pruebas de transportador_.

Voy a cerrar este tema por ahora. Todavía está abierto a discusión.

@qiyigg Empecé a usar el nuevo debugger con el inspector de Chrome y el nodo8 y funciona bien.

¿Puede el equipo del transportador comenzar a marcar la documentación del antiguo código de depuración que usa debuggerCommon.js como DEPRECATED ? Estoy de acuerdo con @monkpit en que las cosas son un poco confusas ahora donde el código no funciona con node8, pero no está marcado como obsoleto. En última instancia, este antiguo código de depuración debería eliminarse si nunca se va a arreglar con node8.

Si echa un vistazo al documento de depuración, ya hemos mencionado que el depurador no funcionará en el nodo 8
https://github.com/angular/protractor/blob/master/docs/debugging.md#enabled -control-flow
"Nota: el depurador de transportador y el explorador de elementos no se pueden usar para Node.js 8+"

Una cosa a tener en cuenta es: no todos usan Node 8+, no podemos decir que el depurador esté obsoleto y obligar a todos a usar async / await (aunque lo haremos dentro de Google).

Aparentemente, pasar a Node 8+ y async / await tiene muchos beneficios y deberíamos pasar a él eventualmente, pero no es un trabajo fácil ya que tenemos que cambiar gran parte de nuestro código existente. Estamos trabajando en esto dentro de Google e intentamos acumular más experiencia sobre migración (incluso herramientas de migración) y esperamos que también pueda ayudar a los usuarios fuera de Google eventualmente.

Creo que lo que podríamos hacer ahora es aclarar este error, digamos, lanzar una excepción: el explorador / depurador de elementos no es compatible con el nodo 8+ en lugar de "Error: no se puede encontrar el módulo '_debugger'", un PR será muy bienvenido.

@qiyigg Sugeriría hacer esa advertencia en negrita y TODAS LAS MAYÚSCULAS . Es un poco difícil de captar en esa página, porque hay muchas palabras.

Estoy muy contento con el nuevo depurador porque puedo usar intellij para ejecutar mis pruebas. esto es mucho mejor que el explorador de elementos (que me gustó bastante) pero usar mi IDE para depurar pruebas es una gran victoria.

@qiyigg Trabajo en una empresa que fabrica pinters de gran producción. Debido a que cambiamos todas nuestras UI para usar Angular (¡hurra!) Decidimos usar Transportador para las pruebas de UI E2E (también hurra). Aparte de estas pruebas E2E, también tenemos pruebas reales de extremo a extremo que funcionan en un sistema en ejecución real. Todos los casos de prueba para ese sistema de prueba se especifican en el marco de prueba de Microsft TFS y usamos un DSL para escribirlos. Este DSL carga los objetos de página que escribimos para nuestra UI a través de un transportador iniciado interactivamente (por lo que el explorador de elementos) y llama a métodos en ellos para ejecutar sus pruebas.

Hasta ahora todo va bien, diría usted, tenemos miles de estas pruebas y se ejecutan realmente "como un usuario". Lo que hago con esta conversación es que el explorador de elementos se elimina con el nuevo nodo (y el nuevo nodo es obligatorio para actualizar Angular). Esto también significa que, de repente, toda nuestra base de pruebas dejaría de funcionar.

Obtengo el cambio con async / wait y reescribiremos nuestros objetos de página obviamente para admitirlo, pero no hay una alternativa real para insertar comandos de transportador de forma remota, ¿verdad? Siempre tendré que pasar "una prueba" que solo llame al "depurador", y luego comunicarme directamente con Chrome para llamar a un comando en los objetos de mi página y luego ejecutar la siguiente llamada de "depurador" que probablemente tendré que ejecutar. en un bucle while.

¿No se admitieron escenarios como estos? ¿No lo estarán? O simplemente me estoy perdiendo algo ... Para mí, la depuración de errores en sus pruebas / código es completamente diferente a la instrucción remota de comandos de prueba. Este último es algo que el explorador de elementos solía facilitar :)

Para al menos compartir cuál es mi solución actual, he escrito esta prueba, que es la única prueba del sistema que ejecuto con transportador (CompletableFuture es una clase de ayuda obviamente):

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

Luego, esta prueba continúa ejecutándose mientras conecto mi cliente WS (C #) que actúa como un puente entre las especificaciones de prueba y los objetos de la página. Este puente luego indica al navegador que cargue los objetos de la página y las pruebas comiencen a ejecutarse.

El último comando que envío al navegador es, por supuesto

global.systemTestsDone.complete()

para que la prueba se complete normalmente. No creo que esto sea realmente horrible, lo único extraño es que ahora tengo que abusar de una prueba para entrar en modo interactivo. Si a más personas les falta una funcionalidad como esta, podría ser una buena idea incluirla nuevamente en el transportador. No me refiero a un protocolo devtools completo, sino a la opción de dejar el transportador en funcionamiento mientras, por ejemplo, usas la consola de Chrome o el código de Visual Studio como "explorador de elementos".

agregue @vikerman , quien se hará cargo de las cosas del transportador.

@vikerman ¿Debo hacer una solicitud de función a partir de los comentarios anteriores?

En resumen, lo que me gustaría tener en transportador (ya que --elementExplorer ya no funciona con las versiones recientes de node.js) es un modo que simplemente inicia el transportador, ignora los archivos de especificaciones y sigue ejecutándose hasta que se llame a algún método manual (algo así como protractor.exit() ?). Podríamos iniciar el transportador en este modo con node --inspect , cargar algunos objetos de página y conectar un ejecutor de pruebas externo al protocolo del depurador y ejecutar las pruebas de forma interactiva.

esto sería realmente bueno si alguien lo arregla. Actualmente estoy usando nvm como solución alternativa.
uso nvm para instalar el nodo 7.10.1 y activar elementExplorer desde allí.
un poco de solución poco convincente, pero funciona por ahora

Bajé al nodo v6 para que esto funcione y ahora no puedo ejecutar mi aplicación Angular 6 porque el nodo 6 no es compatible con Angular 6+. Parece que Angular ahora apunta al nodo> = 8.9.0.

¿Existe un buen trabajo que pueda seguir para obtener un transportador REPL sin tener que ejecutar dos versiones de nodo?

Tengo el mismo error en la consola. Estoy siguiendo estas instrucciones que se dan aquí.
https://github.com/angular/protractor/blob/master/docs/debugging.md#enabled -control-flow

pero sigue apareciendo el mismo error 👎

Entonces, ¿es este el final de browser.pause () / browser.debugger ()? Parece que deberíamos alejarnos del flujo de control y usar el depurador de nodos.
https://github.com/angular/protractor/blob/master/docs/debugging.md

El uso de NVM para cambiar a la versión de nodo 7.10.1 solucionó el problema browser.pause () para mí.

Entiendo que async / await es el camino a seguir, y el uso de Webstorm para depurar pruebas con puntos de interrupción es absolutamente perfecto, pero donde siento que la ausencia de elementExplorer es su uso extendido en el paquete elementor , que fue una forma deliciosa de probar piezas de forma interactiva de código sobre la marcha (en el cuadro multifunción) en lugar de ejecutar toda la prueba desde cero.
Con el proceso de depuración dado para nodejs 8+, los comandos de la consola no resuelven las promesas mientras el inspector está en pausa en un punto de interrupción, lo cual me doy cuenta de que es contrario a la intuición, pero todo esto ha significado un aumento sutil en el tiempo dedicado a escribir / pruebas de depuración y pérdida de una función ampliamente utilizada (según el número de respuestas en este hilo).
¿Hay algún plan para tener un sustituto de la antigua función elementExplorer en transportador?

@ woppa684 La sugerencia me está funcionando bien. Gracias @ woppa684. Me acabo de mudar al nodo 10+ que tiene repl-await (por lo que puede esperar en la consola)

Agregué todos mis archivos de configuración como referencia, espero que ayude a alguien:

Especificación de depuración interactiva especial: 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",

transportador.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;

Yo uso browser.sleep(100000) lugar de browser.pause()