Protractor: Element Explorer не работает на Node 8

Я не думаю, что в настоящее время мы тестируем узел 8, поэтому имеет смысл, что это может быть нарушено. Спасибо, что подняли этот вопрос!

Я попытаюсь разобраться в этом в ближайшие несколько дней, но я бы очень приветствовал пиар, чтобы исправить это!

_debugger и устаревший отладчик CLI были удалены в узле 8: https://github.com/nodejs/node/commit/90476ac6ee

Есть обновления по этому поводу?

Не могли бы мы узнать, каковы планы по поддержке Node 8? :)

С Node v8, настроенным на выход в LTS в октябре, может быть, мы сможем получить обновление?

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

Согласно https://nodejs.org/en/docs/guides/debugging-getting-started/#legacy -debugger,
команда node.js переводит пользователей на новый inspect API.

Планируется ли команда снова заставить это работать либо с помощью API проверки, либо с помощью чего-то другого?

Такая же ошибка https://github.com/node-inspector/node-inspector/issues/1025#issuecomment -339202842
Уже 4 месяца

Также https://stackoverflow.com/questions/44662442/node-inspector-not-starting

Я начал разбираться в этом. Вот несколько предположений о том, как это может работать:

Насколько я могу судить, изменения должны произойти в debuggerCommons.js

Вместо require('_debugger'); необходимо использовать require('inspector'); ( документы здесь ). Затем вы можете открыть инспектор, создать сеанс, подключиться к нему, а затем использовать session.post и протокол Chrome DevTools для отправки сообщений для добавления точек останова.

Когда у меня будет время, я пойму пиарщик.

@phenomnomnomnominal Привет, это здорово! Могу я узнать, когда вы готовы сделать пиар? Поскольку эта функция очень полезна, было бы здорово, если бы ее можно было создать в ближайшее время. Это сильно ускорит наше развитие.
Спасибо!

@phenomnomnominal Привет, мы планируем поддерживать node 8.0 в последнее время.

Только то, что я изложил выше. Я собирался попробовать это сегодня вечером.

@phenomnomnomnominal , это здорово, большое спасибо!

@phenomnomnominal Привет, есть ли обновления?

Я начал пробовать, но у меня были проблемы с Selenium при попытке запустить тесты (какие-нибудь советы?). Я собираюсь провести еще немного времени во вторник вечером. Новый API совсем другой, но я не предвижу никаких серьезных проблем.

хорошо, спасибо большое. У меня должно быть немного времени после понедельника, может быть, я тоже смогу это изучить после этого.

Я попал ... где-то? Оказалось, что отладка отладчика не так проста, как я ожидал. @qiyigg ты

Я разберусь сегодня, спасибо!

Сегодня вечером у меня будет еще немного времени, мы сможем сравнить записи позже.

Привет, есть ли прогресс по этому вопросу за последнюю неделю? Это все еще происходит.

Для отладчика / проводника транспортира мы решили не поддерживать его в узле 8.

1. Отладчик / проводник Protractor в основном предназначен для отладки тестов в потоке управления; но поток управления - это то, что мы не поощряем (особенно у нас есть собственный async / await в узле 8) и в конечном итоге будет устаревшим.
2. После расследования мы обнаружили, что для исправления этого может потребоваться много усилий, и этого не стоит делать по причине 1.
3. Мы работаем над предоставлением новых отладочных документов для узла 8 с использованием встроенного инструмента async / await и Chrome Inspector, который даст больше возможностей, чем оригинальный отладчик.
4. @phenomnomnominal Если у вас есть какой-то прорыв в этом

У вас есть какое-то расчетное время прибытия для этого? Мы жадно болтаем за это там, где я работаю. Пытаемся научить некоторых людей тестированию e2e, но у нас нет возможности перейти в режим отладки и фактически выполнить код в контексте, в котором происходит сбой. Если есть способ сделать это помимо этого, пожалуйста, дайте мне знать.

@ KellyR-STCU
Привет,
Для узла версии <8 вы можете использовать исходный процесс / инструменты отладки.
Для версии узла> = 8 вы можете следить за новым процессом отладки, который использует собственный async / await Node.js для обработки асинхронного вызова (так что нам не нужно полагаться на поток управления и старый отладчик) и использовать инспектор Chrome ( или любой другой отладчик узла) для отладки

У нас есть некоторые документы, чтобы описать, как отлаживать с помощью встроенного async / await и chrome Inspector.
отладка с отключенным потоком управления
как использовать async / await

Надеюсь, это поможет

@qiyigg как насчет elementExplorer?

@monkpit он не будет работать в Node 8 по той же причине. У нас нет полной замены для этого, но вы можете открыть и использовать инструмент разработки Chrome во время отладки, он не будет конфликтовать с отладкой транспортира, как мы сталкивались ранее.

@qiyigg, хорошо, поскольку в центре внимания была функция elementExplorer, я оставлю ее открытой.

Решение также представляет собой небольшую проблему, поскольку требует переписывания существующих тестов, потому что «вы не можете использовать сочетание async / await и потока управления». Было бы неплохо, если бы вы могли указать, какой подход использовать для каждого теста, чтобы переключение не требовало обновления всех существующих тестов.

@ uriah-ascend
да, я должен признать, что это не идеальное решение. Но, как я упоминал выше, поток управления в конечном итоге будет удален . Преобразование наших тестов в async / await - это то, что мы должны делать постепенно, и это действительно дает нам лучший опыт отладки.
Думаю, один из способов сделать это - создать отдельную тестовую конфигурацию для новых тестов, а затем постепенно их преобразовывать.

@qiyigg есть ли руководство или документация по преобразованию в async / await?

Достаточно хорошая информация в тех двух ссылках, которые он предоставил под названием отладка с отключенным потоком управления и
как использовать async / await

Второй вариант, вероятно, является более пошаговым для преобразования.

После возникновения проблемы с browser.pause() на узле 8.

Я следил за Disabled Control Flow .

Вместо запуска node --inspect-brk bin/protractor <config_file> и выполнения отладки в браузере я использую node inspect $(which protractor) <config_file> за которым следует debug> cont в терминале.

Теперь у меня есть эквивалент browser.pause() .

т.е. используйте debugger вместо browser.pause()

Просто для проверки: у нас есть большая кодовая база транспортира, которую нельзя сразу преобразовать в async / await. Хороший способ сделать это - сначала преобразовать все «асинхронные» действия транспортира, используя цепочку обещаний, верно? Таким образом, все должно работать независимо от того, включен поток управления или нет.
Спасибо !

Цепочка обещаний будет работать независимо от того, включен поток управления или нет, но иногда это немного беспорядочно, и вы, возможно, захотите когда-нибудь снова изменить его на async / await?
Итак, я предлагаю иметь две отдельные конфигурации на данный момент, поместить новый тестовый / преобразованный тест в новую конфигурацию, которая отключает control_flow, и постепенно избавляться от старой.

Проблема в том, что мы разделяем множество функций между тестами, поэтому, если мы перенесем эти функции в async await, мы нарушим все тесты, которые их используют и которые не были перенесены в async await (подсказка: МНОГО). И если мы сохраним две версии одной и той же функции, мы рискуем, что они разойдутся.
Поэтому мне кажется, что либо мы перемещаем все, чтобы обещать цепочку в качестве промежуточного шага перед переходом к async / await, либо мы настраиваем babel для преобразования нашей тестовой базы кода (используя что-то вроде этого: https://stackoverflow.com/questions/ 28708975 / transpile-async-await-offer-with-babel-js?), Чтобы мы могли написать async / await и перенести его на что-то, что можно запускать как с потоком управления, так и без него.
Кто-нибудь знает, делалось ли это раньше?
В любом случае кажется, что было бы неплохо указать пути миграции для больших кодовых баз в readme ...

Имеет смысл, на самом деле мы думаем об этом в последнее время.
Я разговаривал с внутренней командой, которая перенесла большую базу кода на async / await.
Они обнаружили, что это приведет к появлению тонких ошибок и условий гонки, если они изменит общие утилиты на цепочку обещаний, и они уже отказались от этого.
Они скопировали некоторые общие утилиты и перевели их в async / await. Я не знаю, является ли это лучшим решением, но, как вы упомянули, у него будет некоторый несовпадающий риск.
Мы также работаем над написанием некоторого инструмента миграции, чтобы упростить его, но эти инструменты, возможно, не будут работать внешне.

В любом случае, мы недавно работаем над планом миграции и должны дать некоторые советы по миграции где-нибудь в ближайшем будущем.

Спасибо за ответ, приятно знать, что это проблема,
заглядывают!
Я думаю, что было бы неплохо создать конкретный вопрос о том, как
перенести большие кодовые базы, чтобы люди видели, как над этим работают.

Le 16 janv. 2018 19:58, «qiyi» [email protected] автор:

Имеет смысл, на самом деле мы думаем об этом в последнее время.
Я разговаривал с внутренней командой, которая перенесла большую базу кода на
асинхронный / ожидание.
Они обнаружили, что он внесет небольшие ошибки и условия гонки, если они
изменили общие утилиты на цепочку обещаний, и они уже отказались от этого.
Они скопировали некоторые общие утилиты и перевели их в async / await. я
не знаю, лучшее ли это решение, но, как вы упомянули,
иметь некоторый расходящийся риск
Мы также работаем над написанием некоторого инструмента миграции, чтобы упростить его, но
инструменты, возможно, не будут работать внешне.

Как бы то ни было, мы недавно работаем над планом миграции и должны дать некоторые
совет по миграции куда-нибудь в ближайшее время.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/angular/protractor/issues/4307#issuecomment-358068096 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AHHOgiLEdFS-xZVcOKmO1EB-CID53cryks5tLPFagaJpZM4NtM1n
.

Привет, народ! Есть ли обходной путь?

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$ 

Также возникла ошибка Error: Cannot find module '_debugger' , OSX.

Этот выпуск открыт уже почти год. По-прежнему нет прогресса?

@ajklotz Я могу подтвердить, что он все еще работает только с Node 7. Я использовал nvm для переключения между версиями Node, чтобы использовать проводник элементов. Больно, но работает!

@ajklotz @monkpit @mraible Если вы можете работать с узлом 8 или выше, я рекомендую вам попробовать сделать следующее:

1. Посмотрите это видео «Транспортир: новая надежда» https://youtu.be/6aPfHrSl0Qk?t=1051 , особенно начиная с 17:31
2. Переключитесь на использование узла 8 или выше
3. Преобразуйте свои тесты для использования ключевых слов ES2017 async / await: https://github.com/angular/protractor/blob/master/docs/async-await.md
4. Добавьте SELENIUM_PROMISE_MANAGER: false, в свой protractor.conf.js
5. Используйте новую функцию debugger и используйте инспектор Chrome для отладки: https://github.com/angular/protractor/blob/master/docs/debugging.md#disabled -control-flow

Я сделал это с помощью моих собственных тестов транспортира и подтвердил, что он работает.

@ajklotz @monkpit @mraible Вот пример, в котором я преобразовал тесты Protractor для использования async / await: https://github.com/buildbot/buildbot/pull/4074/files

Все, что возвращает Promise, вы вставляете перед ним await например:

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

Если функция имеет вызов await , то перед сигнатурой функции должна стоять async .

Если вы вызываете функцию с помощью async , тогда вы должны await it.

Это займет некоторое время, но как только вы это сделаете, это сработает.

@rodrigc В моей области тестов уже используется async / await, суть этой проблемы в том, что из командной строки protractor --elementExplorer не работает, если вы не используете узел 7.

FWIW, похоже, такая языковая функция, как async/await , в любом случае не должна иметь значения. Возможно, своп как временное решение имеет смысл, но Protractor не подразумевает зависимости от этого стиля.

@monkpit Да, вы совершенно правы. Основная причина вашей проблемы заключается в том, что в этой строке: https://github.com/angular/protractor/blob/master/lib/debugger/debuggerCommons.js#L1 импортируется модуль _debugger , который недоступен на node8. Таким образом, все, что использует debuggerCommons.js будет работать на node8, включая elementExplorer .

Итак, если вы хотите использовать node8 или выше и отлаживать с помощью транспортира, ключом является использование async/await и выполнение шагов по адресу: https://github.com/angular/protractor/blob/master/docs/ debugging.md

Старая отладка не работает.

Либо он не будет исправлен (это нормально, я могу использовать обходной путь), либо он будет обновлен для использования узла 8+ (это тоже нормально). Но я бы так или иначе хотел увидеть официальный ответ.

@monkpit

Я думаю, что ответ кроется в этом комментарии @qiyigg.

Для отладчика / проводника транспортира мы решили не поддерживать его в узле 8 ...

Из того, что я слышал от @qiyigg, когда я разговаривал с ним, в настоящее время в команде делается упор на _отключение потока управления в тестах Protractor_.

Я пока закрываю этот выпуск. Это все еще открыто для обсуждения.

@qiyigg Я начал использовать новый debugger с инспектором Chrome и node8, и он хорошо работает.

Может ли команда транспортира начать помечать документацию для старого отладочного кода, в котором debuggerCommon.js как УСТАРЕВШИЙ ? Я согласен с @monkpit, что сейчас все немного запутано, когда код не работает с node8, но он не помечен как устаревший. В конечном итоге этот старый код отладки следует просто удалить, если он никогда не будет исправлен с помощью node8.

Если вы посмотрите на отладочный документ, мы уже упоминали, что отладчик не будет работать на Node 8.
https://github.com/angular/protractor/blob/master/docs/debugging.md#enabled -control-flow
«Примечание: отладчик Protractor и обозреватель элементов нельзя использовать для Node.js 8+»

Следует иметь в виду следующее: не все используют Node 8+, мы не можем сказать, что отладчик устарел и заставить всех использовать async / await (хотя мы сделаем это внутри Google).

По-видимому, переход на Node 8+ и async / await имеет много преимуществ, и мы должны в конечном итоге перейти на него, но это непростая работа, поскольку нам нужно изменить большую часть нашего существующего кода. Мы работаем над этим внутри Google и пытаемся накопить больше опыта в области миграции (даже инструментов миграции) и надеемся, что в конечном итоге это также поможет пользователям за пределами Google.

Я думаю, что сейчас мы могли бы сделать эту ошибку более понятной, скажем, выбросить исключение: обозреватель / отладчик элементов не поддерживается для Node 8+ вместо «Ошибка: не удается найти модуль '_debugger'», PR будет очень приветствовали.

@qiyigg Я бы посоветовал выделить это предупреждение жирным шрифтом и ВСЕМИ ЗАГЛАВНЫМИ буквами . На этой странице немного сложно уловить, потому что там много слов.

я действительно доволен новым отладчиком, потому что я могу использовать intellij для запуска моих тестов. это намного лучше, чем обозреватель элементов (который мне скорее понравился), но использование моей IDE для отладки тестов - огромная победа.

@qiyigg Я работаю в компании, которая производит пинтеры большого производства. Поскольку мы изменили весь наш пользовательский интерфейс, чтобы использовать Angular (ура!), Мы решили использовать Protractor для тестов UI E2E (тоже ура). Помимо этих тестов E2E, у нас также есть настоящие сквозные тесты, которые работают на реальной работающей системе. Все тестовые примеры для этой тестовой системы указаны в среде тестирования Microsft TFS, и мы используем DSL для их написания. Этот DSL загружает объекты страницы, которые мы написали для нашего пользовательского интерфейса, через интерактивно запускаемый транспортир (например, обозреватель элементов) и вызывает на них методы для выполнения своих тестов.

Вы бы сказали, что пока все хорошо, у нас есть тысячи этих тестов, и они действительно выполняются «как пользователь». Что я сделал из этого разговора, так это то, что проводник элементов удаляется с новым узлом (и новый узел является обязательным для обновления Angular). Это также означает, что внезапно вся наша тестовая база перестанет работать.

Я получаю изменение с помощью async / wait, и мы, очевидно, перепишем наши объекты страницы, чтобы поддерживать его, но нет реальной альтернативы удаленной вставке команд транспортира, верно? Мне всегда придется проходить «тест», который вызывает только «отладчик», а затем напрямую связываться с хромом, чтобы вызвать команду на объектах моей страницы, а затем перейти к следующему вызову «отладчика», который мне тогда, вероятно, придется запустить в цикле while.

Разве подобные сценарии не поддерживаются? Неужели они не будут? Или мне просто что-то не хватает ... Для меня отладка ошибок в ваших тестах / коде полностью отличается от удаленного указания тестовых команд. Последнее - то, что облегчил обозреватель элементов :)

Чтобы хотя бы поделиться своим текущим решением, я написал этот тест, который является единственным системным тестом, который я выполняю с транспортиром (CompletableFuture, очевидно, является вспомогательным классом):

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

Затем этот тест продолжает выполняться, пока я подключаю свой (C #) клиент WS, который действует как мост между спецификациями теста и объектами страницы. Затем этот мост дает браузеру команду загрузить объекты страницы, и тесты начинают выполняться.

Последняя команда, которую я отправляю браузеру, конечно же

global.systemTestsDone.complete()

так что тест завершится нормально. Не думаю, что это действительно ужасно, единственная странность заключается в том, что теперь мне приходится злоупотреблять тестом, чтобы перейти в интерактивный режим. Если у других людей не хватает такой функции, было бы неплохо снова включить ее в транспортир. Я имею в виду не весь протокол разработчика, а возможность оставить транспортир работающим, когда вы, например, используете консоль кода Chrome или Visual Studio в качестве «проводника элементов».

добавьте @vikerman , который возьмет на себя работу с транспортиром.

@vikerman Следует ли мне сделать запрос функции из приведенных выше комментариев?

Короче говоря, то, что я хотел бы иметь в транспортире (поскольку --elementExplorer больше не работает с последними версиями node.js), - это режим, который просто запускает транспортир, игнорирует файлы спецификаций и просто продолжает работать до тех пор, пока не будет вызван какой-либо ручной метод. (что-то вроде protractor.exit() ?). Мы могли бы запустить транспортир в этом режиме с помощью node --inspect , загрузить некоторые объекты страницы и подключить внешнее средство запуска тестов к протоколу отладчика и запустить тесты в интерактивном режиме.

это было бы действительно хорошо, если бы кто-нибудь это исправил. В настоящее время я использую nvm в качестве обходного пути.
Я использую nvm для установки узла 7.10.1 и запуска elementExplorer оттуда.
немного хромой обходной путь, но он работает сейчас

Я перешел на узел v6, чтобы заставить это работать, и теперь я не могу запустить приложение Angular 6, потому что узел 6 не поддерживается в Angular 6+. Похоже, что Angular теперь нацелен на узел> = 8.9.0.

Есть ли хорошая работа, которой я могу следовать, чтобы получить REPL транспортира без необходимости запускать две версии узла?

У меня такая же ошибка в консоли. Я следую этим инструкциям, данным здесь
https://github.com/angular/protractor/blob/master/docs/debugging.md#enabled -control-flow

но все равно возникает такая же ошибка 👎

Так это конец для browser.pause () / browser.debugger ()? Похоже, нам следует отойти от потока управления и использовать отладчик узлов.
https://github.com/angular/protractor/blob/master/docs/debugging.md

Использование NVM для переключения на версию узла 7.10.1 устранило для меня проблему browser.pause ().

Я понимаю, что async / await - это путь вперед, и использование Webstorm для отладки тестов с точками останова абсолютно незаметно, но я считаю, что отсутствие elementExplorer - это его расширенное использование в пакете elementor , что было восхитительным способом интерактивного тестирования частей кода на лету (в омнибоксе) вместо того, чтобы запускать весь тест с нуля.
С данным процессом отладки для nodejs 8+ команды из консоли не разрешают обещания, пока инспектор приостановлен в точке останова, что, как я понимаю, противоречит интуиции, но все это означало небольшое увеличение времени, затрачиваемого на запись / отладочные тесты и потеря широко используемой функции (по количеству ответов в этом потоке).
Есть ли планы заменить старую функцию elementExplorer в транспортире?

@ woppa684 Предложение мне

Добавил все мои файлы конфигурации для справки, надеюсь, это кому-то поможет:

Специальная спецификация интерактивной отладки - 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",

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;

Я использую browser.sleep(100000) вместо browser.pause()