Protractor: مستكشف العناصر لا يعمل على العقدة 8

لا أعتقد أننا نختبر حاليًا ضد العقدة 8 ، لذا فمن المنطقي أن يتم كسر هذا. شكرا من أجل انجاح هذا!

سأحاول البحث في هذا الأمر في الأيام القليلة المقبلة ، لكن العلاقات العامة لإصلاح ذلك ستكون موضع ترحيب كبير!

_debugger ومصحح أخطاء CLI القديم تمت إزالتهما في Node 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 بترحيل المستخدمين إلى واجهة برمجة تطبيقات الفحص الجديدة.

هل هناك خطط من الفريق لإعادة هذا العمل مرة أخرى مع واجهة برمجة تطبيقات الفحص أو أي نهج آخر؟

نفس الخطأ 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 لإرسال الرسائل لإضافة نقاط التوقف.

سأواجه مشكلة في العلاقات العامة عندما أحصل على بعض الوقت.

phenomnomnominal يا هذا رائع! هل لي أن أعرف متى تكون متاحًا لإجراء العلاقات العامة؟ نظرًا لأن هذه الوظيفة مفيدة جدًا ، فسيكون من الرائع إنشاؤها قريبًا. سوف يسرع تنميتنا كثيرا.
شكرا!

phenomnomnominal مرحبًا ،

فقط ما أشرت إليه أعلاه. كنت أخطط للحصول على صدع هذا المساء.

phenomnomnominal هذا رائع ، شكرًا جزيلاً!

phenomnomnominal مرحبًا ، أي تحديثات حتى الآن؟

لقد بدأت في تجربة ، لكنني كنت أواجه مشكلات مع السيلينيوم عند محاولة إجراء الاختبارات (أي نصائح؟). سأحظى ببعض الوقت الإضافي ليلة الثلاثاء. واجهة برمجة التطبيقات الجديدة مختلفة تمامًا ، لكنني لا أتوقع أي مشكلات حقيقية.

حسنا شكرا كثيرا. من المفترض أن أمضي بعض الوقت بعد يوم الاثنين ، ربما يمكنني أيضًا النظر في الأمر بعد ذلك.

لدي ... في مكان ما؟ تبين أن تصحيح الأخطاء لمصحح الأخطاء ليس سهلاً كما كنت أتمنى. qiyigg هل لديك فرصة للنظر في أي شيء؟

سأبحث فيه اليوم ، شكرا!

سآخذ المزيد من الوقت هذا المساء أيضًا ، يمكننا مقارنة الملاحظات لاحقًا.

مرحباً ، أي تقدم في هذا الموضوع في الأسبوع الماضي؟ لا يزال يحدث.

بالنسبة لمصحح / مستكشف أخطاء المنقلة ، قررنا عدم دعمه في العقدة 8.

1. مصحح / مستكشف المنقلة مصمم بشكل أساسي لتصحيح الأخطاء في اختبار التحكم في التدفق ؛ لكن التحكم في التدفق شيء لا نشجعه (خاصة أن لدينا عدم تزامن / انتظار أصلي في العقدة 8) وسيتم إهماله في النهاية.
2. بعد التحقيق ، وجدنا أنه قد يحتاج إلى الكثير من الجهد لإصلاحه ولا يستحق القيام بذلك وفقًا للسبب 1.
3. نحن نعمل على توفير مستندات تصحيح أخطاء جديدة للعقدة 8 باستخدام أداة فحص عدم التزامن / انتظار والكروم الأصلية ، والتي ستوفر تجربة أفضل من مصحح الأخطاء الأصلي.
4. phenomnomnominal إذا كان لديك بعض الاختراق حول هذا الأمر ، فنحن نرغب في مراجعته. اشكرك على مجهودك.

هل لديك نوع من الوقت المقدر للوصول لهذا؟ نحن نمتلك القليل من أجل ذلك حيث أعمل. محاولة تعليم بعض الأشخاص حول اختبار e2e وليس لدينا طريقة للذهاب إلى وضع التصحيح وتنفيذ التعليمات البرمجية في السياق الذي يحدث فيه الفشل. إذا كانت هناك طريقة يمكن القيام بها خارج هذا ، فيرجى إبلاغي بذلك.

@ KellyR-STCU
أهلا،
بالنسبة لإصدار العقدة <8 ، يمكنك استخدام عملية / أدوات التصحيح الأصلية.
بالنسبة لإصدار العقدة> = 8 ، يمكنك اتباع عملية التصحيح الجديدة ، والتي تستخدم Node.js الأصلي غير المتزامن / انتظار للتعامل مع المكالمة غير المتزامنة (حتى لا نحتاج إلى الاعتماد على تدفق التحكم ومصحح الأخطاء القديم) ، واستخدام عارض الكروم ( أو أي مصحح عقدة آخر) لتصحيح الأخطاء

لدينا بعض المستندات لوصف كيفية تصحيح الأخطاء باستخدام مفتش chrome غير المتزامن / الانتظار الأصلي
تصحيح الأخطاء مع تعطيل تدفق التحكم
كيفية استخدام غير متزامن / انتظار

آمل أن يساعد

qiyigg ماذا عن elementExplorer؟

monkpit لن يعمل في Node 8 لنفس السبب. ليس لدينا بديل كامل لذلك ، ولكن يمكنك فتح أداة تطوير الكروم واستخدامها أثناء التصحيح ، ولن تتعارض مع تصحيح أخطاء المنقلة كما واجهنا من قبل.

qiyigg حسنًا ، نظرًا لأن ميزة elementExplorer كانت محور المشكلة ، سأتركها مفتوحة.

يمثل الحل أيضًا مشكلة صغيرة لأنه يتطلب إعادة كتابة الاختبارات الحالية لأنه "لا يمكنك استخدام مزيج من عدم التزامن / انتظار وتدفق التحكم". سيكون من الجيد إذا كان بإمكانك تحديد الطريقة التي يجب اتباعها لكل اختبار بحيث لا يتطلب التبديل تحديث جميع الاختبارات الحالية.

@ uriah- تصاعد
نعم ، يجب أن أعترف أنه ليس حلاً مثاليًا. ولكن كما ذكرت أعلاه ، فإن التحكم في التدفق هو شيء ستتم إزالته في النهاية. تحويل اختباراتنا إلى غير متزامن / انتظار شيء يجب أن نفعله تدريجيًا ، وهو يمنحنا تجربة تصحيح أخطاء أفضل.
أعتقد أن إحدى الطرق التي يمكنك القيام بها هي أن يكون لديك تكوين اختبار منفصل للاختبارات الجديدة ، ثم تحويلها تدريجيًا.

qiyigg هل هناك دليل أو توثيق حول كيفية التحويل إلى غير متزامن / انتظار؟

معلومات جيدة في هذين الرابطين قدمها بعنوان تصحيح الأخطاء مع تعطيل تدفق التحكم و
كيفية استخدام غير متزامن / انتظار

والثاني هو على الأرجح أكثر من خطوة خطوة للتحويل.

بعد حدوث مشكلة مع browser.pause() على العقدة 8.

لقد اتبعت تعطيل التحكم في التدفق .

بدلاً من تشغيل node --inspect-brk bin/protractor <config_file> وإجراء التصحيح في المتصفح ، أستخدم node inspect $(which protractor) <config_file> متبوعًا بـ debug> cont في المحطة.

الآن لدي ما browser.pause() .

على سبيل المثال ، استخدم debugger بدلاً من browser.pause()

فقط للتحقق: لدينا قاعدة كود منقلة كبيرة ، والتي لا يمكن تحويلها إلى غير متزامن / انتظار الكل مرة واحدة. هناك طريقة جيدة للقيام بذلك وهي تحويل جميع إجراءات المنقلة "غير المتزامنة" باستخدام تسلسل الوعد ، أليس كذلك؟ بهذه الطريقة يجب أن تعمل الأشياء سواء تم تمكين تدفق التحكم أم لا.
شكرا !

ستعمل تسلسل الوعد سواء تم تمكين تدفق التحكم أم لا ، ولكنه نوع من الفوضى في بعض الأحيان وقد ترغب في تغييره مرة أخرى إلى غير متزامن / انتظار في يوم من الأيام؟
لذا فإن اقتراحي هو أن يكون لديك تكوينان منفصلان في الوقت الحالي ، ضع الاختبار الجديد / المحول في التكوين الجديد الذي يعطل control_flow والتخلص من القديم تدريجيًا

تكمن المشكلة في أننا نشارك الكثير من الوظائف بين الاختبارات ، لذلك إذا قمنا بنقل هذه الوظائف إلى غير متزامن في انتظار أننا سنكسر جميع الاختبارات التي تستخدمها والتي لم يتم ترحيلها إلى غير متزامن في انتظار (تلميح: الكثير). وإذا احتفظنا بنسختين من نفس الوظيفة ، فإننا نخاطر بجعلهما يتباعدان.
لذلك يبدو لي أننا إما أن ننقل كل شيء لنعد بالتسلسل كخطوة وسيطة قبل الانتقال إلى غير متزامن / انتظار ، أو قمنا بإعداد بابل لنقل قاعدة كود الاختبار الخاصة بنا (باستخدام شيء من هذا القبيل: https://stackoverflow.com/questions/ 28708975 / transpile-async-await-offer-with-babel-js؟) ، حتى نتمكن من كتابة غير متزامن / انتظار ونقله إلى شيء يمكن تشغيله إما بتدفق التحكم أو بدونه.
لا أحد يعرف ما إذا كان هذا قد تم القيام به من قبل؟
على أي حال ، يبدو أنه سيكون من الجيد إعطاء مسارات للهجرات لقواعد الرموز الكبيرة في الملف التمهيدي ...

يبدو منطقيًا ، في الواقع نحن نفكر فيه مؤخرًا.
لقد تحدثت إلى فريق داخلي قام بترحيل قاعدة رمز كبيرة إلى عدم التزامن / الانتظار.
وجدوا أنه سيحدث أخطاء خفية وظروف عرقية إذا قاموا بتغيير الأدوات الشائعة إلى سلسلة الوعد وتخلوا بالفعل عن القيام بذلك.
قاموا بنسخ بعض الأدوات الشائعة وترجمتها إلى غير متزامن / انتظار. لا أعرف ما إذا كان هذا هو الحل الأفضل ، ولكن كما ذكرت ، سيكون له بعض المخاطر المتباينة
نحن نعمل أيضًا على كتابة بعض أدوات الترحيل لتسهيل الأمر ، ولكن ربما لا تعمل الأدوات خارجيًا.

على أي حال ، نحن نعمل على خطة الترحيل مؤخرًا ، وينبغي أن نقدم بعض النصائح المتعلقة بالترحيل في مكان ما في المستقبل القريب.

شكرًا لك على ردك ، من الجيد معرفة أن هذه مشكلة
يجري النظر في!
أعتقد أنه من الجيد إنشاء قضية محددة لكيفية ذلك
ترحيل قواعد أكواد كبيرة ، حتى يرى الناس أنه يتم العمل عليها.

لو 16 يناير. 2018 19:58 ، "qiyi" [email protected] écrit:

يبدو منطقيًا ، في الواقع نحن نفكر فيه مؤخرًا.
لقد تحدثت إلى فريق داخلي قام بترحيل قاعدة رموز كبيرة إلى
غير متزامن / انتظار.
ووجدوا أنه سيقدم أخطاء خفية وظروف العرق إذا قاموا بذلك
غيروا الأدوات الشائعة إلى سلسلة الوعد وتخلوا بالفعل عن القيام بذلك.
قاموا بنسخ بعض الأدوات الشائعة وترجمتها إلى غير متزامن / انتظار. أنا
لا أعرف ما إذا كان هذا هو الحل الأفضل ، ولكن كما ذكرت ، فسيكون كذلك
لديها بعض المخاطر المتباينة
نحن نعمل أيضًا على كتابة بعض أدوات الترحيل لتسهيل الأمر ، ولكن
ربما لا تعمل الأدوات خارجيًا.

على أي حال ، نحن نعمل على خطة الهجرة مؤخرًا ، ويجب أن نقدم بعضًا منها
نصائح الهجرة في مكان ما في المستقبل القريب.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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$ 

تعاني أيضًا من OSX Error: Cannot find module '_debugger' .

ظل هذا العدد مفتوحًا منذ ما يقرب من عام. لا يزال هناك تقدم؟

ajklotz يمكنني أن أؤكد أنه لا يزال يعمل فقط مع Node 7. لقد كنت أستخدم nvm للتبديل بين إصدارات Node من أجل استخدام مستكشف العناصر. إنه ألم ، لكنه يعمل!

ajklotz monkpitmraible إذا كنت قادرًا على التشغيل باستخدام Node 8 أو أعلى ، فأوصيك بمحاولة القيام بما يلي:

1. شاهد هذا الفيديو "منقلة: أمل جديد" https://youtu.be/6aPfHrSl0Qk؟t=1051 ، تحديدًا بدءًا من الساعة 17:31 تقريبًا
2. قم بالتبديل إلى استخدام Node 8 أو أعلى
3. قم بتحويل اختباراتك لاستخدام الكلمات الرئيسية غير المتزامنة / انتظار ES2017: https://github.com/angular/protractor/blob/master/docs/async-await.md
4. أضف SELENIUM_PROMISE_MANAGER: false, إلى protractor.conf.js
5. استخدم وظيفة debugger واستخدم chrome inspector لتصحيح الأخطاء: https://github.com/angular/protractor/blob/master/docs/debugging.md#disabled -control-flow

لقد فعلت ذلك من خلال اختبارات المنقلة الخاصة بي وأؤكد أنها تعمل.

ajklotzmonkpitmraible هنا مثال حيث I تحويلها الاختبارات المنقلة لاستخدام المتزامن / انتظار: https://github.com/buildbot/buildbot/pull/4074/files

أي شيء يُرجع الوعد ، فإنك تلتصق بـ await أمامه مثل:

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

إذا كانت الوظيفة تحتوي على استدعاء لـ await ، فيجب أن يكون أمام توقيع الوظيفة async .

إذا استدعت دالة بـ async ، فيجب عليك await عليها.

يستغرق الأمر بعض الوقت ولكن بمجرد القيام بذلك ، فإنه يعمل.

rodrigc منطقة الاختبارات الخاصة بي تستخدم بالفعل غير متزامن / انتظار ، protractor --elementExplorer إلا إذا كنت تستخدم العقدة 7.

FWIW ، يبدو أن ميزة لغة مثل async/await يجب ألا تكون ذات صلة على أي حال. ربما يكون التبادل كإصلاح لسد الفجوة أمرًا منطقيًا ، لكن المنقلة لا تعني الاعتماد على هذا النمط.

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+ (هذا جيد أيضًا). لكني أرغب في رؤية رد رسمي بطريقة أو بأخرى.

تضمين التغريدة

أعتقد أن الإجابة تكمن في تعليق qiyigg.

بالنسبة لمصحح / مستكشف أخطاء المنقلة ، قررنا عدم دعمه في العقدة 8 ...

مما سمعته من @ qiyigg عندما تحدثت إليه ، فإن التركيز الحالي في الفريق ينصب على _ تعطيل التحكم في التدفق في اختبارات المنقلة.

سأغلق هذه القضية في الوقت الحالي. لا يزال مفتوحا للنقاش.

qiyigg لقد بدأت في استخدام debugger مع chrome inspector ، و node8 وهو يعمل بشكل جيد.

هل يمكن لفريق المنقلة البدء في وضع علامة على المستندات الخاصة برمز تصحيح الأخطاء القديم الذي يستخدم debuggerCommon.js كمهمل ؟ أتفق مع monkpit على أن الأمور مربكة بعض الشيء الآن حيث لا يعمل الرمز مع node8 ، لكن لم يتم وضع علامة على أنه مهمل. في النهاية ، يجب حذف رمز التصحيح القديم هذا إذا لم يتم إصلاحه مع node8.

إذا ألقيت نظرة على مستند التصحيح ، فقد ذكرنا بالفعل أن مصحح الأخطاء لن يعمل على Node 8
https://github.com/angular/protractor/blob/master/docs/debugging.md#enabled -control-flow
"ملاحظة: لا يمكن استخدام مصحح أخطاء المنقلة ومستكشف العناصر لـ Node.js 8+"

هناك شيء واحد يجب مراعاته وهو: ليس كل شخص يستخدم Node 8+ ، لا يمكننا القول أن مصحح الأخطاء قد تم إهماله ونفرض على الجميع استخدام غير متزامن / انتظار (على الرغم من أننا سنفعل ذلك داخل google).

على ما يبدو ، فإن الانتقال إلى Node 8+ و async / wait له فوائد عديدة ويجب أن ننتقل إليه في النهاية ، لكنه ليس بالأمر السهل حيث يتعين علينا تغيير الكثير من التعليمات البرمجية الحالية. نحن نعمل على هذا داخل google ونحاول تجميع المزيد من الخبرة حول الترحيل (حتى أدوات الترحيل) ونأمل أن يساعد أيضًا المستخدمين خارج Google في النهاية.

أعتقد أن ما يمكننا فعله الآن هو جعل هذا الخطأ أكثر وضوحًا ، على سبيل المثال ، طرح استثناء: مستكشف العناصر / مصحح الأخطاء غير مدعوم للعقدة 8+ بدلاً من "خطأ: لا يمكن العثور على الوحدة '_debugger'" ، ستكون العلاقات العامة شديدة جدًا رحب.

qiyigg أود أن أقترح لجعل هذا التحذير في CAPS جريئة وALL. من الصعب بعض الشيء الإمساك بها في تلك الصفحة ، لأن هناك الكثير من الكلمات.

أنا سعيد حقًا بمصحح الأخطاء الجديد لأنه يمكنني استخدام intellij لإجراء اختباراتي. هذه طريقة أفضل من مستكشف العناصر (التي أحببتها بالأحرى) ولكن استخدام IDE الخاص بي لتصحيح الأخطاء يعد فوزًا كبيرًا.

qiyigg أنا أعمل في شركة تنتج كميات كبيرة من البينتالات. نظرًا لأننا غيرنا جميع واجهات المستخدم لدينا لاستخدام Angular (يا هلا!) قررنا استخدام منقلة لاختبارات UI E2E (يا مهلا أيضًا). بصرف النظر عن اختبارات E2E ، لدينا أيضًا اختبارات حقيقية من البداية إلى النهاية تعمل على نظام تشغيل فعلي. تم تحديد جميع حالات الاختبار لنظام الاختبار هذا في إطار اختبار Microsft TFS ونستخدم DSL لكتابتها. يقوم DSL بتحميل كائنات الصفحة التي كتبناها لواجهة المستخدم الخاصة بنا من خلال منقلة تعمل بشكل تفاعلي (وبالتالي مستكشف العناصر) وتستدعي الطرق عليها لتنفيذ اختباراتها.

حتى الآن جيد جدًا ، يمكنك القول ، لدينا الآلاف من هذه الاختبارات ويتم إجراؤها حقًا "كمستخدم". ما استخلصته من هذه المحادثة هو أن مستكشف العناصر يتم إسقاطه مع العقدة الجديدة (والعقدة الجديدة إلزامية لترقية Angular). هذا يعني أيضًا أنه فجأة ستتوقف قاعدة الاختبار بالكامل عن العمل.

لقد حصلت على التغيير مع عدم التزامن / الانتظار وسنعيد كتابة كائنات صفحتنا بشكل واضح لدعمها ، لكن لا يوجد بديل حقيقي لإدخال أوامر المنقلة عن بُعد ، أليس كذلك؟ سأضطر دائمًا إلى اجتياز "اختبار" لا يستدعي سوى "مصحح الأخطاء" ، ثم أتواصل مباشرة مع Chrome لاستدعاء أمر على كائنات صفحتي ثم تشغيل استدعاء "مصحح الأخطاء" التالي الذي ربما يتعين علي تشغيله بعد ذلك في حلقة.

هل كانت مثل هذه السيناريوهات غير مدعومة؟ أليسوا كذلك؟ أم أنني أفتقد شيئًا ما ... بالنسبة لي ، فإن تصحيح الأخطاء في الاختبارات / الكود يختلف تمامًا عن توجيه أوامر الاختبار عن بُعد. هذا الأخير هو عنصر يستخدمه مستكشف العناصر لتسهيل :)

لمشاركة ما هو الحل الحالي الخاص بي على الأقل ، لقد كتبت هذا الاختبار ، وهو اختبار النظام الوحيد الذي أجريه باستخدام المنقلة (من الواضح أن 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

يستمر هذا الاختبار في العمل أثناء توصيل عميل WS (C #) الذي يعمل كجسر بين مواصفات الاختبار وكائنات الصفحة. ثم يوجه هذا الجسر المتصفح لتحميل كائنات الصفحة ويبدأ تنفيذ الاختبارات.

آخر أمر أرسلته إلى المتصفح هو بالطبع

global.systemTestsDone.complete()

بحيث يكتمل الاختبار بشكل طبيعي. لا أعتقد أن هذا أمر مروع حقًا ، الشيء الغريب الوحيد هو أنني مضطر الآن إلى إساءة استخدام اختبار للدخول في وضع تفاعلي. إذا كان هناك عدد أكبر من الأشخاص يفتقدون وظائف مثل هذه ، فقد يكون من الجيد تضمينها في المنقلة مرة أخرى. لا أقصد بروتوكول devtools بالكامل ولكن خيار ترك المنقلة قيد التشغيل أثناء استخدامك ، على سبيل المثال ، لوحدة التحكم الخاصة بالكروم أو كود الاستوديو المرئي كـ "مستكشف العناصر".

أضف 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 () بالنسبة لي.

أدرك أن عدم التزامن / الانتظار هو الطريق إلى الأمام ، واستخدام Webstorm لتصحيح الأخطاء باستخدام نقاط التوقف أمر سلس تمامًا ، ولكن حيث أشعر بغياب elementExplorer هو استخدامه الموسع في حزمة elementor ، والتي كانت طريقة ممتعة لاختبار الأجزاء بشكل تفاعلي من الكود سريعًا (في المربع متعدد الاستخدامات) بدلاً من تشغيل الاختبار بالكامل من البداية.
مع عملية تصحيح الأخطاء المحددة لـ nodejs 8+ ، فإن الأوامر من وحدة التحكم لا تحل الوعود أثناء توقف المفتش مؤقتًا عند نقطة توقف ، وهو ما أدرك أنه غير بديهي ، ولكن كل هذا يعني زيادة طفيفة في الوقت الذي يقضيه في الكتابة / تصحيح الأخطاء وفقدان ميزة مستخدمة على نطاق واسع (حسب عدد الردود في هذا الموضوع).
هل هناك أي خطط لاستبدال ميزة elementExplorer القديمة في المنقلة؟

@ woppa684 الاقتراح يعمل بشكل جيد بالنسبة لي. شكرا @ woppa684. لقد انتقلت للتو إلى العقدة 10+ التي تنتظر إعادة الانتظار (لذا يمكنك الانتظار في وحدة التحكم)

تمت إضافة جميع ملفات التكوين الخاصة بي للرجوع إليها ، ونأمل أن تساعد شخصًا ما:

مواصفات تصحيح الأخطاء التفاعلية الخاصة - 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()