Protractor: Explorador de elemento não funciona no Nó 8

Não acho que estamos testando atualmente no nó 8, então faz sentido que ele esteja quebrado. Obrigado por trazer isso à tona!

Vou tentar aprofundar isso nos próximos dias, mas um PR para consertar isso seria muito bem-vindo!

_debugger e o depurador CLI legado foram removidos no Nó 8: https://github.com/nodejs/node/commit/90476ac6ee

Alguma atualização sobre isso?

Podemos saber quais são os planos para o suporte do Nó 8? :)

Com o Node v8 definido para entrar no LTS em outubro, talvez pudéssemos obter uma atualização?

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

De acordo com https://nodejs.org/en/docs/guides/debugging-getting-started/#legacy -debugger,
a equipe do node.js está migrando usuários para a nova API inspect.

Há planos da equipe para fazer com que isso funcione novamente com a API inspect ou alguma outra abordagem?

Mesmo erro https://github.com/node-inspector/node-inspector/issues/1025#issuecomment -339202842
4 meses já

Além disso, https://stackoverflow.com/questions/44662442/node-inspector-not-starting

Comecei a dar uma olhada nisso. Aqui estão alguns palpites sobre como atualizar isso pode funcionar:

Pelo que eu posso dizer, as mudanças precisam acontecer em debuggerCommons.js

Em vez de require('_debugger'); ele precisa usar require('inspector'); ( documentos aqui ). Você pode então abrir o inspetor, criar uma sessão, conectar-se a ela e usar session.post e o protocolo Chrome DevTools para enviar as mensagens para adicionar os pontos de interrupção.

Terei uma chance em um PR quando tiver algum tempo.

@phenomnomnominal Ei, isso é ótimo! Posso saber quando você estará disponível para fazer o PR? Como essa funcionalidade é tão útil, seria ótimo se ela pudesse ser criada em breve. Isso vai acelerar muito nosso desenvolvimento.
Obrigado!

@phenomnomnominal Olá, estamos planejando oferecer suporte ao node 8.0 recentemente. Qual é o seu plano atual para corrigir esse problema?

Apenas o que descrevi acima. Eu estava planejando dar uma olhada nisso esta noite.

@phenomnomnominal isso é ótimo, muito obrigado!

@phenomnomnominal Olá, alguma atualização até agora?

Comecei a tentar, mas estava tendo problemas com o Selenium ao tentar executar os testes (alguma dica?). Vou ter mais algum tempo na terça à noite. A nova API é bem diferente, mas não prevejo nenhum problema real.

ok, muito obrigado. Devo ter algum tempo depois de segunda-feira, talvez também possa dar uma olhada nisso depois disso.

Eu tenho ... em algum lugar? Acontece que depurar o depurador não é tão simples quanto eu esperava. @qiyigg você teve a chance de olhar alguma coisa?

Vou dar uma olhada nisso hoje, obrigado!

Terei mais algum tempo esta noite também, podemos comparar as notas mais tarde.

Olá, algum progresso neste assunto na última semana? Ainda está ocorrendo.

Para o depurador / explorador de transferidor, decidimos não oferecer suporte no nó 8.

1. Depurador / explorador de prolongador projetado principalmente para teste de depuração no fluxo de controle; mas o fluxo de controle é algo que não encorajamos (especialmente temos async / await nativos no nó 8) e será eventualmente descontinuado.
2. Depois de investigar, descobrimos que pode ser necessário muito esforço para corrigi-lo e não vale a pena fazer isso de acordo com o motivo 1.
3. Estamos trabalhando para fornecer novos documentos de depuração para o nó 8 usando a ferramenta nativa async / await e chrome inspector, que proporcionará uma experiência melhor do que o depurador original.
4. @phenomnomnominal Se você tiver alguma descoberta sobre isso, gostaríamos de analisá-lo. Obrigado pelo seu esforço.

Você tem algum tipo de HEC para isso? Estamos ansiosos por onde eu trabalho. Tentamos ensinar algumas pessoas sobre o teste e2e e não temos como entrar no modo de depuração e realmente executar o código no contexto em que a falha ocorre. Se houver outra maneira de fazer isso fora disso, entre em contato.

@ KellyR-STCU
Oi,
Para a versão do nó <8, você pode usar o processo / ferramentas de depuração originais.
Para a versão do nó> = 8, você pode seguir o novo processo de depuração, que usa Node.js nativa async / await para lidar com a chamada assíncrona (para que não precisemos depender do fluxo de controle e do depurador antigo) e usar o inspetor de cromo ( ou qualquer outro depurador de nó) para depurar

Temos alguns documentos para descrever como depurar com async / await nativo e inspetor de cromo
depuração com fluxo de controle desabilitado
como usar assíncrono / esperar

Espero que ajude

@qiyigg e o elementExplorer?

@monkpit não funcionará no Nó 8 pelo mesmo motivo. Não temos um substituto completo para isso, mas você pode abrir e usar a ferramenta de desenvolvimento do Chrome durante a depuração, ela não entrará em conflito com a depuração do transferidor, como encontramos antes.

@qiyigg ok, como o recurso elementExplorer era o foco do problema, vou deixá-lo aberto.

A solução também é um pouco problemática, pois requer a reescrita dos testes existentes porque "você não pode usar uma combinação de async / await e o fluxo de controle". Seria bom se você pudesse especificar qual abordagem seguir por teste, de forma que a troca não exigisse a atualização de todos os testes existentes.

@ uriah-ascend
sim, devo admitir que não é uma solução perfeita. Mas, como mencionei acima, o fluxo de controle é algo que será eventualmente removido . Converter nossos testes em async / await é algo que devemos fazer gradualmente e nos dá uma melhor experiência de depuração.
Acho que uma maneira de fazer é ter uma configuração de teste separada para novos testes e convertê-los gradualmente.

@qiyigg existe algum guia ou documentação de como converter para async / await?

Informações muito boas nesses dois links que ele forneceu intitulados debugging with control flow disabled e
como usar assíncrono / esperar

O segundo é provavelmente mais um passo a passo para a conversão.

Depois de ter problemas com browser.pause() no nó 8.

Eu segui o Fluxo de Controle Desativado .

Em vez de executar node --inspect-brk bin/protractor <config_file> e depurar no navegador, uso node inspect $(which protractor) <config_file> seguido por debug> cont no terminal.

Agora eu tenho browser.pause() equivalente.

ou seja, use debugger no lugar de browser.pause()

Só para verificar: temos uma grande base de código do transferidor, que não pode ser convertida para assíncrona / aguardar de uma vez. Uma boa maneira de fazer isso é primeiro converter todas as ações do transferidor "assíncronas" usando o encadeamento de promessa, certo? Desta forma, as coisas devem funcionar quer o fluxo de controle esteja habilitado ou não.
Obrigado !

O encadeamento de promessas funcionará se o fluxo de controle estiver habilitado ou não, mas às vezes é meio confuso e você pode querer alterá-lo de volta para assíncrono / aguardar algum dia?
Portanto, minha sugestão é ter duas configurações separadas por enquanto, colocar o novo teste / teste convertido na nova configuração que desativa o control_flow e se livrar do antigo gradualmente

O problema é que compartilhamos muitas funções entre os testes, então se migrarmos essas funções para async await estaremos quebrando todos os testes que as usam e que não foram migrados para async await (dica: MUITO). E se mantivermos duas versões da mesma função, corremos o risco de vê-las divergentes.
Portanto, parece-me que movemos tudo para prometer encadeamento como uma etapa intermediária antes de passar para async / await ou configuramos o babel para transpilar nossa base de código de teste (usando algo assim: https://stackoverflow.com/questions/ 28708975 / transpile-async-await-proposal-with-babel-js?), Para que possamos escrever async / await e transpilá-lo para algo que pode ser executado com ou sem fluxo de controle.
Alguém sabe se isso já foi feito antes?
Em qualquer caso, parece que seria uma boa ideia fornecer caminhos de migração para grandes bases de código no readme ...

Faz sentido, na verdade estamos pensando nisso recentemente.
Conversei com uma equipe interna que migrou uma grande base de código para async / await.
Eles descobriram que introduziriam bugs sutis e condições de corrida se mudassem os utilitários comuns para a cadeia de promessa e já desistiram de fazer isso.
Eles copiaram alguns utilitários comuns e os traduziram para async / await. Não sei se é a melhor solução, mas como você mencionou, terá algum risco de divergência
Também estamos trabalhando para escrever alguma ferramenta de migração para torná-la mais fácil, mas as ferramentas talvez não funcionem externamente.

De qualquer forma, estamos trabalhando em um plano de migração recentemente e devemos dar alguns conselhos sobre migração em algum lugar no futuro próximo.

Obrigado pela sua resposta, é bom saber que é um problema que é
sendo examinado!
Acho que seria uma boa ideia criar um problema específico sobre como
migre grandes bases de código, para que as pessoas vejam que está sendo trabalhado.

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

Faz sentido, na verdade estamos pensando nisso recentemente.
Conversei com uma equipe interna que migrou uma grande base de código para
assíncrono / esperar.
Eles descobriram que isso introduziria bugs sutis e condições de corrida se eles
mudou utils comuns para cadeia de promessa e eles já desistiram de fazer isso.
Eles copiaram alguns utilitários comuns e os traduziram para async / await. eu
não sei se é a melhor solução, mas como você mencionou,
tem algum risco divergente
Também estamos trabalhando para escrever alguma ferramenta de migração para torná-la mais fácil, mas
as ferramentas talvez não funcionem externamente.

De qualquer forma, estamos trabalhando em um plano de migração recentemente e devemos dar alguns
conselhos de migração em algum lugar no futuro próximo.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/angular/protractor/issues/4307#issuecomment-358068096 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AHHOgiLEdFS-xZVcOKmO1EB-CID53cryks5tLPFagaJpZM4NtM1n
.

Oi, pessoal! Existe alguma solução alternativa?

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$ 

Também experimentando o Error: Cannot find module '_debugger' , OSX.

Esta edição está aberta há quase um ano. Ainda sem progresso?

@ajklotz Posso confirmar que ainda funciona apenas com o Node 7. Tenho usado o nvm para alternar entre as versões do Node para usar o explorador de elemento. É uma dor, mas funciona!

@ajklotz @monkpit @mraible Se você consegue rodar com o Nó 8 ou superior, recomendo que tente fazer o seguinte:

1. Assista a este vídeo "Transferidor: Uma Nova Esperança" https://youtu.be/6aPfHrSl0Qk?t=1051 , especificamente a partir de 17:31
2. Mude para o Nó 8 ou superior
3. Converta seus testes para usar as palavras-chave assíncronas / aguardam ES2017: https://github.com/angular/protractor/blob/master/docs/async-await.md
4. Adicione SELENIUM_PROMISE_MANAGER: false, ao seu protractor.conf.js
5. Use a nova função debugger e use o inspetor de cromo para depurar: https://github.com/angular/protractor/blob/master/docs/debugging.md#disabled -control-flow

Fiz isso com meus próprios testes de transferidor e confirmo que funciona.

@ajklotz @monkpit @mraible Aqui está um exemplo em que converti os testes do Protractor para usar async / await: https://github.com/buildbot/buildbot/pull/4074/files

Qualquer coisa que retornar uma promessa, você coloca um await na frente, como:

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

Se uma função tem uma chamada para await , então a assinatura da função deve ter async na frente dela.

Se você chamar uma função com async , você deve await it.

Demora um pouco, mas depois de fazer isso, funciona.

@rodrigc Minha área de testes já está usando async / await, o ponto desse problema é que a partir da linha de comando, protractor --elementExplorer não funciona a menos que você use o nó 7.

FWIW, parece que um recurso de linguagem como async/await deve ser irrelevante de qualquer maneira. Talvez uma troca como solução temporária faça sentido, mas o Protractor não implica dependência desse estilo.

@monkpit Sim, você está absolutamente certo. A causa raiz do seu problema é que nesta linha: https://github.com/angular/protractor/blob/master/lib/debugger/debuggerCommons.js#L1 , o módulo _debugger é importado, que não está disponível em node8. Qualquer coisa que use debuggerCommons.js não funcionará no node8, incluindo elementExplorer .

Portanto, se você deseja usar node8 ou superior e depurar com transferidor, a chave é usar async/await e seguir as etapas em: https://github.com/angular/protractor/blob/master/docs/ debugging.md

O antigo processo de depuração não funcionará.

Ou não vai ser consertado (tudo bem, posso usar a solução alternativa) ou será atualizado para usar o nó 8+ (também está bem). Mas eu adoraria ver uma resposta oficial de uma forma ou de outra.

@monkpit

Acho que a resposta está neste comentário de @qiyigg.

Para o depurador / explorador de transferidor, decidimos não oferecer suporte no nó 8 ...

Pelo que ouvi de @qiyigg quando conversei com ele, o foco atual da equipe está em _desabilitar o fluxo de controle nos testes do Transferidor_.

Vou encerrar esse problema por enquanto. Ainda está aberto para discussão.

@qiyigg Comecei a usar o novo debugger com inspetor de cromo e node8 e funciona bem.

A equipe do transferidor pode começar a marcar a documentação do código de depuração antigo que usa debuggerCommon.js como DESCONTINUADO ? Concordo com @monkpit que as coisas estão um pouco confusas agora, onde o código não funciona com o node8, mas não está marcado como obsoleto. Em última análise, esse código de depuração antigo deve ser excluído se nunca for corrigido com o node8.

Se você der uma olhada no documento de depuração, já mencionamos que o depurador não funcionará no Nó 8
https://github.com/angular/protractor/blob/master/docs/debugging.md#enabled -control-flow
"Observação: o depurador do Protractor e o explorador de elemento não podem ser usados ​​para Node.js 8+"

Uma coisa a ter em mente é: nem todo mundo está usando o Node 8+, não podemos dizer que o depurador está obsoleto e obrigar todos a usar async / await (embora façamos isso dentro do google).

Aparentemente, mudar para o Node 8+ e async / await tem muitos benefícios e devemos mudar para ele eventualmente, mas não é uma tarefa fácil, pois temos que mudar muito do nosso código existente. Estamos trabalhando nisso dentro do google e tentamos acumular mais experiência sobre migração (até mesmo ferramentas de migração) e esperamos que também possa ajudar usuários fora do google eventualmente.

Acho que o que podemos fazer agora é deixar esse erro mais claro, digamos, lançar uma exceção: o explorador / depurador de elemento não é compatível com o Nó 8+ em vez de "Erro: não é possível encontrar o módulo '_debugger'", um PR será muito bem-vindo.

@qiyigg Eu sugiro fazer esse aviso em negrito e em MAIÚSCULAS . É um pouco difícil entender nessa página, porque há muitas palavras.

Estou muito feliz com o novo depurador porque posso usar o intellij para executar meus testes. isso é muito melhor do que o explorador de elemento (do qual gostei bastante), mas usar meu IDE para depurar testes é uma grande vitória.

@qiyigg Eu trabalho em uma empresa que faz pinters de grande produção. Como mudamos todas as nossas IUs para usar Angular (ui!), Decidimos usar o Protractor para os testes de IU E2E (também ui). Além desses testes E2E, também temos testes reais de ponta a ponta que funcionam em um sistema em execução real. Todos os casos de teste para esse sistema de teste são especificados na estrutura de teste Microsft TFS e usamos uma DSL para escrevê-los. Esta DSL carrega os objetos de página que escrevemos para nossa IU por meio de um transferidor iniciado interativamente (portanto, o explorador de elemento) e chama métodos neles para executar seus testes.

Até aí tudo bem, você diria, temos milhares desses testes e eles são executados realmente "como um usuário". O que entendi dessa conversa é que o explorador de elemento foi eliminado com o novo nó (e o novo nó é obrigatório para atualizar o Angular). Isso também significa que, de repente, toda a nossa base de teste para de funcionar.

Eu obtenho a mudança com async / wait e iremos reescrever nossos objetos de página obviamente para suportá-la, mas não há alternativa real para inserir comandos transferidores remotamente, certo? Sempre terei que passar em "um teste" que apenas chama "depurador" e, em seguida, me comunicar diretamente com o cromo para chamar um comando em meus objetos de página e, em seguida, executar a próxima chamada de "depurador" que provavelmente terei de executar em um loop while.

Cenários como esses não eram suportados? Não vão ser? Ou estou apenas perdendo alguma coisa ... Para mim, depurar erros em seus testes / código é totalmente diferente de instruir remotamente comandos de teste. O último é algo que o explorador de elementos usou para facilitar :)

Para pelo menos compartilhar minha solução atual, escrevi este teste, que é o único teste de sistema que executo com transferidor (CompletableFuture é uma classe auxiliar, 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

Este teste continua em execução enquanto eu conecto meu cliente WS (C #) que atua como uma ponte entre as especificações de teste e os objetos de página. Essa ponte então instrui o navegador a carregar os objetos da página e os testes começam a ser executados.

O último comando que envio para o navegador é claro

global.systemTestsDone.complete()

para que o teste seja concluído normalmente. Não acho isso realmente horrível, a única coisa estranha é que agora tenho que abusar de um teste para entrar no modo interativo. Se mais pessoas estiverem perdendo uma funcionalidade como essa, pode ser uma boa ideia incluí-la no transferidor novamente. Não me refiro a um protocolo de devtools inteiro, mas a opção de deixar o transferidor rodando enquanto você, por exemplo, usa o console do Chrome ou o código do Visual Studio como "explorador de elemento".

adicione @vikerman , que assumirá as coisas do Transferidor.

@vikerman Devo fazer uma solicitação de recurso com base nos comentários acima?

Em suma, o que eu gostaria de ter no transferidor (uma vez que --elementExplorer não está mais funcionando com as versões recentes do node.js) é um modo que apenas inicia o transferidor, ignora os arquivos de especificação e continua em execução até alguma chamada de método manual (algo como protractor.exit() ?). Poderíamos iniciar o transferidor neste modo com node --inspect , carregar alguns objetos de página e conectar um executor de teste externo ao protocolo do depurador e executar os testes interativamente.

isso seria muito bom se alguém consertasse isso. Atualmente, estou usando o nvm como uma solução alternativa.
Eu uso o nvm para instalar o nó 7.10.1 e acionar o elementExplorer a partir daí.
um pouco de solução alternativa, mas funciona por agora

Fiz downgrade para o nó v6 para fazer isso funcionar e agora não consigo executar meu aplicativo Angular 6 porque o nó 6 não é compatível com o Angular 6+. Parece que o Angular agora tem como alvo o nó> = 8.9.0.

Existe uma boa solução que eu possa seguir para obter um REPL transferidor sem ter que executar duas versões do nó?

Estou tendo o mesmo erro no console. Estou seguindo as instruções fornecidas aqui
https://github.com/angular/protractor/blob/master/docs/debugging.md#enabled -control-flow

mas ainda assim o mesmo erro está chegando 👎

Então, este é o fim para browser.pause () / browser.debugger ()? Parece que devemos nos afastar do fluxo de controle e usar o depurador de nó.
https://github.com/angular/protractor/blob/master/docs/debugging.md

Usar o NVM para mudar para a versão do nó 7.10.1 corrigiu o problema de browser.pause () para mim.

Eu entendo que async / await é o caminho a seguir, e usar o Webstorm para depurar testes com pontos de interrupção é absolutamente perfeito, mas sinto que a ausência do elementExplorer é seu uso estendido no pacote elementor , que foi uma maneira deliciosa de testar partes interativamente de código em tempo real (na omnibox), em vez de executar todo o teste do zero.
Com o processo de depuração fornecido para nodejs 8+, os comandos do console não resolvem as promessas enquanto o inspetor está pausado em um ponto de interrupção, o que eu percebo ser contra-intuitivo, mas tudo isso significou um aumento sutil no tempo gasto na escrita / testes de depuração e perda de um recurso amplamente usado (indo pelo número de respostas neste segmento).
Há algum plano para substituir o antigo recurso elementExplorer no transferidor?

@ woppa684 A sugestão está funcionando bem para mim. Obrigado @ woppa684. Acabei de mudar para o nó 10+, que tem repl-await (então você pode apenas esperar no console)

Adicionados todos os meus arquivos de configuração para referência, espero que ajude alguém:

Especificação de depuração interativa especial - interativo.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",

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

Eu uso browser.sleep(100000) vez de browser.pause()