Pdf.js: توليد (اختبار) إحصائيات التغطية

unittestcli - يُجري بعض اختبارات الوحدة لـ PDF.js في Node.js (مع الحد الأدنى من تغييرات المصدر ، فقط مع النقل باستخدام بابل).
Browsertest - إجراء الاختبارات في المتصفحات (نقوم باختبار Chrome و Firefox). يعتمد هذا على البرنامج الثنائي الذي تم إنشاؤه بواسطة هدف الإنشاء generic ، والذي يستخدم رمزًا تم تحويله مع babel ثم تجميعه مع حزمة الويب.

لاحظ أنه بينما سيجري browsertest الاختبارات المرجعية ، هناك أيضًا الأمر unittest الذي يقوم بتشغيل المجموعة الكاملة من اختبارات الوحدة في المتصفحات (على عكس unittestcli الذي يشغل مجموعة فرعية فقط من اختبارات الوحدة الحالية).

علاوة على ذلك ، لاحظ أنه يمكن تخطي خطوة "التحويل مع Babel" ، إذا تم تعيين علامة الإنشاء PDFJS_NEXT (إما مثل أعلام الإنشاء الأخرى في gulpfile.js ، أو كوسيطة سطر أوامر). بينما لا تزال الشفرة مجمعة مع Webpack ، فمن الممكن على الأقل تجنب خطوة الترجمة.

@ Rob - أود WI العمل على هذا

إنه لك! أخبرنا (يفضل على IRC) إذا كانت لديك أسئلة.

timvandermeij وأنا أفكر في استخدام كارما tool.It يعمل مع ويمكن التحقق من تنفيذ الاختبارات اسطنبول engine.Statistics مدونة التغطية، ويمكن إجراء تقارير HTML من it.Is انها وسيلة جيدة للبدء؟

باستخدام Karma ، حصلت على تقارير الاختبار https://drive.google.com/file/d/0ByddvU1PKkWaWEZTWHFYT0Y0aTg/view؟usp=sharing
لكن لا يتم عرض إحصائيات تغطية الاختبار https://drive.google.com/file/d/0ByddvU1PKkWaS1ZiT1dobU1DQUk/view؟usp=sharing

@ Divya063 هل يمكنك مشاركة الكود الخاص بك ، على سبيل المثال عن طريق دفع الكود الحالي إلى فرع على شوكة pdf.js على Github؟ أتساءل عما إذا كان يتم تشغيل webpack أو babel عند الضرورة.

وأي إصدار من Node.js تستخدمه؟

شكرًا لك على الرد ، إصدار العقدة هو 6.11.1. ها هو الرابط للفرع https://github.com/Divya063/pdf.js/tree/dev

الأخطاء هي:

Firefox 43.0.0
خطأ في التركيب: قد تظهر إقرارات الاستيراد في المستوى الأعلى فقط
كروم 60.0.3112
خطأ في بناء الجملة غير معلوم: استيراد رمز غير متوقع

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

لقد قمت بتحرير رسالتي الأولية للإشارة إلى مكان تكوين الترجمة في نظام بناء PDF.js. ربما يمكنك محاولة استخدام مكون إضافي موجود لدمج istanbul و babel. يُظهر البحث السريع https://github.com/istanbuljs/babel-plugin-istanbul ، ولكن قد تكون هناك خيارات أخرى أيضًا.

(والإصدار الحالي الثابت من Firefox هو 55. لقد كنت تختبر باستخدام Firefox 43 ، وهو قديم وغير مدعوم. أقترح أن تقوم بالترقية إلى إصدار حديث من Firefox قبل الاختبار مرة أخرى)

@ Rob - W شكرًا لك على الإشارة إلى الأخطاء وسأحدّث قريبًا بالنتائج.

@ Rob - قام WI بنقل الكود باستخدام karma-browserify وقام بترقية إصدار Firefox ولكن لا يزال هناك الكثير من الأخطاء في الظهور ، إليك رابط الفرع https://github.com/Divya063/pdf.js/tree / ديف

هل يمكنك مشاركة رسائل الخطأ؟

وإذا أمكن ، حاول استخدام حزمة الويب بدلاً من المتصفح ، لأن حزمة الويب هي ما نستخدمه بالفعل. يسمح لنا القيام بذلك بأداة الشفرة المستخدمة بالفعل في المتصفح.

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

هل ما زالت هذه القضية معلقة؟ إذا كانت الإجابة بنعم ، أود العمل عليها.

نعم ، لا تتردد في العمل على هذا.

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

npm run coveralls

أحصل على الخطأ التالية

npm run coveralls

> [email protected] coveralls /home/shikhar/Desktop/mozillaPdfJs/pdf.js
> npm run cover -- --report lcovonly && cat ./coverage/lcov.info | coveralls


> [email protected] cover /home/shikhar/Desktop/mozillaPdfJs/pdf.js
> istanbul cover test/**/*.js "--report" "lcovonly"

Running test 1/16: test_first_run
Running test 2/16: test_first_run_incognito
Running test 3/16: test_storage_managed_unavailable
Running test 4/16: test_managed_pref
Running test 5/16: test_local_pref
Running test 6/16: test_managed_pref_is_overridden
Running test 7/16: test_run_extension_again
Running test 8/16: test_running_for_a_while
Running test 9/16: test_browser_update
Running test 10/16: test_browser_update_between_pref_toggle
Running test 11/16: test_extension_update
Running test 12/16: test_unofficial_build
Running test 13/16: test_fetch_is_supported
Running test 14/16: test_fetch_not_supported
Running test 15/16: test_fetch_mode_not_supported
Running test 16/16: test_network_offline
All tests completed.
No coverage information was collected, exit without writing coverage information
[error] "2017-12-17T11:00:06.112Z"  'error from lcovParse: ' 'Failed to parse string'
[error] "2017-12-17T11:00:06.116Z"  'input: ' ''
[error] "2017-12-17T11:00:06.116Z"  'error from convertLcovToCoveralls'

/home/shikhar/Desktop/mozillaPdfJs/pdf.js/node_modules/coveralls/bin/coveralls.js:18
        throw err;
        ^
Failed to parse string
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] coveralls: `npm run cover -- --report lcovonly && cat ./coverage/lcov.info | coveralls`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] coveralls script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/shikhar/.npm/_logs/2017-12-17T11_00_06_136Z-debug.log

حاولت البحث عن هذا هنا وهنا ولكن دون جدوى. أي مساعدة بشأن ما قد تكون المشكلة؟

من الصعب معرفة ذلك بدون رؤية الكود. هل يمكنك إرسال الرمز إلى أحد الفروع حتى يتمكن المساهمون هنا من البحث معك؟

timvandermeij هنا هو عليه. الرجاء تجاهل ملف الأحجار الكريمة. لقد قمت بالفعل بإزالته.

أي تعليقاتtimvandermeij

من خلال القليل من البحث في Google ، يبدو أن هذا الخطأ يعني أن coveralls لا يحصل على بيانات بتنسيق lcov . يمكنك التحقق مما إذا كانت الأوامر الفردية في npm run cover -- --report lcovonly && cat ./coverage/lcov.info | coveralls في الواقع إلى النتائج التي تتوقعها.

تضمين التغريدة
المشكلة الرئيسية حاليا هي هذا البيان
No coverage information was collected, exit without writing coverage information
لهذا السبب ، يظل ملف lcov فارغًا في جميع الأوقات ، وبالتالي يحدث هذا

[error] "2017-12-17T11:00:06.112Z"  'error from lcovParse: ' 'Failed to parse string'
[error] "2017-12-17T11:00:06.116Z"  'input: ' ''
[error] "2017-12-17T11:00:06.116Z"  'error from convertLcovToCoveralls'

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

https://github.com/gotwarlost/istanbul/issues/262
https://github.com/coryhouse/react-slingshot/issues/245
https://github.com/gotwarlost/istanbul/issues/496
والعديد من الآخرين أيضًا ولكن لم يساعد أي منهم فعلاً :(

يتم تمرير الإصدار على travis ( https://travis-ci.org/shikhar-scs/pdf.js/jobs/318422621 ) ولكن مرة أخرى لم يتم إنشاء التغطية.

لست متأكدًا حقًا من سبب حدوث ذلك ، لكنني أجد أيضًا الكثير من الأشخاص الذين فعلوا ذلك بنجاح مع الياسمين ، لذلك يجب أن يكون ذلك ممكنًا. هل يمكنك المحاولة إذا كان https://bryce.fisher-fleig.org/blog/setting-up-istanbul-with-jasmine/index.html مناسبًا لك؟ أولاً ، فقط جرب تلك الخطوات الدقيقة لمعرفة ما إذا كان يعمل بشكل مستقل ، ثم حاول دمجه في PDF.js.

timvandermeij عليه
يتم الآن إنشاء تقارير التغطية أخيرًا. ومع ذلك ، فأنا بحاجة إلى التحويل ثم الاختبار لأنه يظهر مشاكل مع بيانات الاستيراد والتصدير
Transformation error for /home/shikhar/Desktop/mozillaPdfJs/pdf.js/web/ui_utils.js ; return original code 'import' and 'export' may appear only with 'sourceType: "module"' (16:0)
يظهر هذا الخطأ مع كل ملف js وسأعمل عليه وأرسل PR قريبًا.

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

ها هم: البناء يمر ويدعو للتغطية .

تقارير التغطية

ومع ذلك ، نظرًا لوجود بيانات الاستيراد والتصدير ، حتى بعد الوصول إلى هذه الملفات ، لم يتم اختبارها بالكامل ، وبالتالي نحصل على تقارير تغطية بنسبة 0٪ بقدر ما أعلم أنني بحاجة إلى جعل هذه الملفات مهتمة بـ ES6 قبل اختبار الياسمين وهذا يثبت أنه مشكلة. كيف أقدم كود ES6 إلى الياسمين؟
هل يمكنني إجراء تغييرات في ملف gulp كما هو مذكور هنا http://jpsierens.com/use-es6-right-now/ ؟

أنت بالفعل تقترب من الحل. من تقارير التغطية ، يبدو أنك تقوم بتشغيل التغطية على ملفات lib ، والتي يجب تحويلها بالفعل إلى ES6 (راجع https://github.com/mozilla/pdf.js/blob/6ac9e1c5ed0d5f067872b8482724c171c79566b2/gulpfile. js # L965 و https://github.com/mozilla/pdf.js/blob/6ac9e1c5ed0d5f067872b8482724c171c79566b2/gulpfile.js#L985). أم أن المشكلة هي أن وحدة الاختبارات نفسها لا يتم نقلها؟ لست على دراية بكيفية عمل ذلك بالضبط ، ولكن إذا كان هذا هو الحال ، فقد تكون بعض التغييرات على ملف Gulpfile لاختبار الوحدة ضرورية.

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

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

كانت المشكلة أنني كنت أجري الاختبارات في المجلد الخطأ. يحتوي المجلد build>lib بالفعل على المشروع بأكمله بتنسيق ES6 وقد قمت الآن بتصحيح الأمر بالكامل ، أي مسار الياسمين والمعاطف.
مشكلة أخرى كانت عبارة --report lcovonly . بطريقة سحرية (لا أعرف حقًا السبب) عندما أزلت هذا الجزء من خط المآزر ، بدأت التقارير في الظهور. ربما كان علي أن أهتم أكثر بها

يمكنك التحقق مما إذا كانت الأوامر الفردية في npm run cover - --report lcovonly && cat ./coverage/lcov.info | المآزر في الواقع تعيد النتائج التي تتوقعها.

شكرا لتوضيح هذا.

أخيرًا ، نحن قادرون على إنشاء تقارير: تادا: وعلى الرغم من أنها تبدو حزينة بعض الشيء ، إلا أن قراءة الملفات بالضبط ستوفر لك سبب -

1. يتم احتساب جميع العبارات الشرطية غير المنفذة على أنها "غير مغطاة".
2. يتم أيضًا اعتبار جميع عبارات التخصيص غير المنفذة على أنها "غير مغطاة".

من الواضح أنني لم أحمل التقارير التي تم إنشاؤها بنفسي ولكني استضافتها على رابط هنا http://pdfjscoveragereport.bitballoon.com . يرجى زيارة هذه الروابط وستحصل على التقرير الدقيق المتوقع.

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

ولكن لا يزال npm run coveralls سيقدم تقارير التغطية الكاملة بهذا التنسيق الموجود في المجلد build/lib/coverage/lcov-report .

آمل أن يساعد كل هذا أخيرًا ، رغم ذلك ، فإن مشكلتنا الأخيرة هي عرض هذه التقارير بطريقة ما على المعاطف.

هذا هو الرابط لأحدث بنائي. https://travis-ci.org/shikhar-scs/pdf.js
هذا هو الرابط لآخر التزاماتي .

بصرف النظر عن التقارير التي لم يتم إنشاؤها على المآزر.io أعتقد أن كل شيء على ما يرام. هل يجب أن أقوم بإنشاء علاقات عامة لأنها ستجذب الانتباه من العديد من الأشخاص وقد تحل هذه المشكلة في وقت مبكر بدلاً من ذلك؟

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

أتساءل عما إذا كان من الممكن تشغيل التغطية على الملفات المصدر بدلاً من الملفات المدمجة. هذا يجعل الأمر أسهل للفهم ، لأنه الآن على http://pdfjscoveragereport.bitballoon.com/lib/display/metadata.js.html أرى السطر 28 لم تتم تغطيته بينما هذا ليس رمزنا ، ولكن تم إنشاؤه تلقائيًا بدلاً من ذلك. إذا اتضح أنه صعب ، فيمكننا فقط تنفيذ النهج الحالي كإصدار أول والقيام بذلك في مشكلة متابعة.

هل يجب أن أقوم بإنشاء علاقات عامة لأنها ستجذب الانتباه من العديد من الأشخاص وقد تحل هذه المشكلة في وقت مبكر بدلاً من ذلك؟

اجل انها فكرة جيدة. يمكننا بعد ذلك بدء عملية المراجعة ومعرفة المشكلات التي تُركت لمعالجة.

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

في حين أنه من المؤكد أنه يمكننا القيام بالكثير من اختبارات الوحدة ، إلا أن هناك أجزاء كبيرة من قاعدة التعليمات البرمجية التي ربما لن تصل إلى أي مكان بالقرب من تغطية الاختبار "الجيدة" الكافية من اختبارات الوحدة وحدها للأسف.

كما هو مذكور في https://github.com/mozilla/pdf.js/issues/8632#issue -241690851 ، هناك عدد قليل من مجموعات الاختبار المختلفة ، وما لم أكن مخطئًا في الحصول على نتائج تغطية من gulp browsertest أيضًا سيكون من الضروري تقريبًا معرفة شكل تغطية الاختبار الفعلي.

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

لقد حاولت هذا الصباح كثيرًا العثور على تقارير التغطية في جميع المجلدات بشكل فردي باستخدام العبارة cd build && cd lib && istanbul cover --include-all-sources jasmine-node test ، وتغيير الدلائل المختلفة باستخدام cd <directory name> والاختبار باستخدام jasmine-node <directory names and js files> ولكن دون جدوى.

على الرغم من أن تقرير الاختبارات يتم إنشاؤه في بعض الأحيان (ليس دائمًا) ، إلا أن هذا يحدث بسبب وجود ملف أو ملفين من ملفات ES6 بتنسيق js موجودان في الدلائل المحددة (والتي تجلب فقط <2 ~ 3٪ من تقارير التغطية). للأسف ، أي ملف js يحتوي على import or export statements خطأ بهذا التنسيق.

Transformation error for /home/shikhar/Desktop/mozillaPdfJs/pdf.js/src/core/arithmetic_decoder.js ; return original code 'import' and 'export' may appear only with 'sourceType: "module"' (183:0) Unable to post-instrument: /home/shikhar/Desktop/mozillaPdfJs/pdf.js/src/core/arithmetic_decoder.js

وبهذا الخطأ ، لا يتم فحص الملف للتغطية على الإطلاق وبالتالي يُرجع تقريرًا بنسبة 0٪.

أتساءل عما إذا كان من الممكن تشغيل التغطية على الملفات المصدر بدلاً من الملفات المدمجة.

مرة أخرى ، يحتوي المجلد المصدر على ملفات تحتوي على بيانات استيراد وتصدير ، وبالتالي تحدث الأخطاء المذكورة أعلاه بسبب عدم فحص الملفات ذات الصلة على الإطلاق ، مما يؤدي إلى تغطية بنسبة 0٪.

وبالتالي ، من الضروري أن نختبر في مجلد البناء نفسه.

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

Snuffleupagus أين تكمن هذه الاختبارات المحددة؟ يمكننا محاولة اختبارها مباشرة باستخدام بيان عقدة الياسمين المذكورة أعلاه.

إذا اتضح أنه صعب ، فيمكننا فقط تنفيذ النهج الحالي كإصدار أول والقيام بذلك في مشكلة متابعة.

نعم ، يمكننا بالأحرى فعل ذلك.

اجل انها فكرة جيدة. يمكننا بعد ذلك بدء عملية المراجعة ومعرفة المشكلات التي تُركت لمعالجة.

بالتأكيد ، سأبدأ بذلك.

أظهر PR في # 9308 مثالاً على تغطية الاختبار لاختبارات الوحدة فقط. تقدم التقارير التي تم إنشاؤها القليل من القيمة لأن مجموعة اختبارات الوحدة لدينا صغيرة جدًا. لمزيد من التفاصيل ، راجع https://github.com/mozilla/pdf.js/pull/9308#issuecomment -353588039

لذلك ، لإجراء اختبارات المتصفح ، نحتاج إلى:

1. طريقة لتوليد بيانات التغطية.
2. طريقة لاسترداد بيانات التغطية (وتحميلها على المعاطف).

للعنوان 1) ، يجب تعديل gulpfile.js لإضافة أدوات الكود اختياريًا ، والتي يتم تصديرها إلى الكائن window.__coverage__ في المستعرض. قد يكون gulp-istanbul مفيدًا. تبدو الوثائق قليلة ، لكني وجدت مثالاً على https://stackoverflow.com/questions/38208735/no-window-coverage-object-is-created-by-istanbul-phantomjs. نحن لا نستخدم PhantomJS ، ولكن يمكنك قراءة السؤال والإجابة ومقالة المدونة المرتبطة لتعميق فهمك لكيفية عمل كل شيء.

بعد الانتهاء من الخطوة 1 ، ستحتوي اختبارات المتصفح على متغير window.__coverage__ (أو أيًا كان ما وضعته في معلمة التكوين coverageVariable ). للحصول على تقارير التغطية:

1. قم بتعديل عداء الاختبار (https://github.com/mozilla/pdf.js/blob/e081a708c36cb2aacff7889048863723fcf23671/test/driver.js) لنشر نتيجة التغطية بـ XMLHttpRequest إلى خادم الاختبار.
2. في خادم الاختبار (https://github.com/mozilla/pdf.js/blob/e081a708c36cb2aacff7889048863723fcf23671/test/test.js) ، قم بتسجيل خطاف جديد لتلقي نتائج الاختبار ، واكتب ذلك في ملف باستخدام fs Node.js API (ربما بعد بعض المعالجة اللاحقة ، مثل تحويله إلى تنسيق lcov إذا لزم الأمر).
3. قم بتحميل التقرير إلى المعاطف (على سبيل المثال باستخدام أمر "المعاطف" كما هو موضح في # 9308).

@ Rob - W شكرًا لمثل هذه المراجعة التفصيلية. سأتابع وسأعود في أقرب وقت ممكن.

يقدم هذا التعليق نصائح للتنفيذ ، ويعالج الأسئلة من https://github.com/mozilla/pdf.js/pull/9308#issuecomment -353710595

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

يمكن إجراء هذه الأجهزة أثناء تشغيل البرنامج (على سبيل المثال ، عند تشغيل istanbul cover من سطر الأوامر ، سيعترض istanbul المكالمات إلى Node.js require وقم بتحويل الكود باستخدام الأجهزة قبل تحميل الوحدة النمطية ) ، أو بشكل منفصل عن التنفيذ (على سبيل المثال ، كما يوضح منشور المدونة: يتم إنشاء الكود الآلي في سطر الأوامر ، ويتم التنفيذ في المتصفح).

في العلاقات العامة الحالية على # 9308 ، أنت تستدعي istanbul cover مع jasmine كبرنامج للتشغيل. كما ذكرت من قبل ، فإن التأثير مشابه لتشغيل gulp unittestcli - على سبيل المثال ، يتم تشغيل الاختبارات على مكتبة سابقة الإنشاء في دليل build/lib (تم تكوين هذا في test/unit/clitests.json ) . هذا يفسر سبب عرض تقرير التغطية الخاص بك 0 تغطية لكل شيء باستثناء build/lib/ (لأن الوحدات النمطية (Node.js) فقط require -d هي في build/lib و build/streams/ - راجع نهاية تعريف المهمة gulp unittestcli ).

للحصول على تقارير تغطية مفيدة ، يفضل أن تكون تقارير التغطية على مستوى الوحدة. هذه خطوة للأمام: تحتاج إلى دمج istanbul في خط أنابيب البناء ، بحيث تتم إضافة الأجهزة عند نقل الشفرة من ES6. بعد ذلك ، يصبح إنشاء تقارير لكل وحدة أكثر صعوبة (ولكن ليس مستحيلًا ، توفر خرائط المصدر النظرية معلومات كافية لتعيين البيانات إلى الملفات الأصلية).
هذا يمثل تحديًا ، ويتطلب فهمًا جيدًا لكيفية استخدام خرائط / وحدات Babel و gulp و istanbul والمصدر (أشرت بالفعل إلى الأماكن ذات الصلة في التعليمات البرمجية المصدر حيث يجمع PDF.js جميع الوحدات لإنشاء ملف PDF.js مكتبة - راجع # 8632). هذه المعرفة مفيدة جدًا ، لذا إذا لم تكن خائفًا من التحديات ، يمكنك استكشاف هذا تحت إرشادي.

ولكن قبل التعمق في الأمر ، لنبدأ بشيء أبسط: الحصول على تقارير التغطية من المتصفح. لدينا طريقتان لإجراء الاختبارات في المتصفح ، unittest و browsertest . نظرًا لأن لدينا بالفعل طريقة سهلة لإجراء اختبارات الوحدة في Node.js ، فلنركز على browsertest . لا تستخدم اختبارات المتصفح وحدات فردية ، ولكن مكتبة PDF.js التي تم إنشاؤها بواسطة الهدف generic gulp ، في GENERIC_DIR ، ويعرف أيضًا باسم build/generic/ . لذلك يكفي إضافة أدوات الكود إلى build/generic . أقترح أخذ build/generic/ كدليل إدخال ، وكتابة النتيجة إلى coverage/build/generic .

بعد القيام بذلك ، تحتاج إلى تغيير test/test_slave.html لعدم تحميل ../build/generic/build/pdf.js دون قيد أو شرط في علامة <script> ، ولكن تحميل مشروط إما ../build/generic/build/pdf.js أو ../coverage/build/generic/build/pdf.js اعتمادًا على بعض معلمات التكوين (للاختبار ، يمكنك فقط كتابة التعليمات البرمجية لعنوان URL الأخير ، فمن السهل جدًا تغيير هذه المعلمة ذات الترميز الثابت لاحقًا بعد الانتهاء من المهمة الأكثر صعوبة المتمثلة في إرسال تقرير التغطية مرة أخرى إلى خادم الاختبار) .

بمجرد استبدال مكتبة pdf.js العادية بمكتبة pdf.js المجهزة ، سيتم إنشاء إحصائيات التغطية أثناء التشغيل التجريبي. يتم تخزين النتيجة في المتغير العالمي window.__coverage__ . عند انتهاء برنامج التشغيل التجريبي في المتصفح ( الطريقة _quit في test / driver.js ) ، يمكنك إجراء تسلسل لهذا التقرير (على سبيل المثال باستخدام JSON.stringify(window.__coverage__) ) وإرساله إلى الخادم باستخدام XMLHttpRequest (راجع المواقع الأخرى في ملف driver.js للحصول على أمثلة - تأكد من إرسال التقرير إلى الخادم قبل إرسال الرسالة /tellMeToQuit ، وإلا فقد لا يتم إرسال تقرير التغطية بشكل صحيح).
يمكنك إضافة معالج جديد لاستدعاء API المخصص الجديد الخاص بك في https://github.com/mozilla/pdf.js/blob/ba5dbc96326518ad716158ef040f61794cc72202/test/test.js . للحصول على أمثلة الرموز ، انظر إلى المكالمات XMLHttpRequest في driver.js (مثل رسالة /tellMeToQuit ) ، وابحث عن المعالج المقابل في test.js . بمجرد استلام JSON المتسلسل من جانب الخادم ، استخدم fs.writeFileSync API لكتابة تقرير التغطية إلى ملف (مرة أخرى ، هناك أمثلة أخرى في test.js توضح كيف يمكنك كتابة الملفات) .

@ Rob - W أنا غير متاح حاليًا حتى العام الجديد ... سألتقط بالتأكيد بعد ذلك

بعد القيام بذلك ، تحتاج إلى تغيير test / test_slave.html لعدم التحميل دون قيد أو شرط ../build/generic/build/pdf.js في

بعد القيام بذلك ، تحتاج إلى تغيير test / test_slave.html لعدم التحميل دون قيد أو شرط ../build/generic/build/pdf.js في

@ Rob - نجح WI في إنشاء معامل مشابه في tests.js (من خلال محاكاة معلمة testFilter) ، ومع ذلك ، فإن دمجها في test/test_slave.html لا يزال يمثل مشكلة بالنسبة لي. بالنسبة لبقية التغييرات ، يرجى زيارة PR مرة أخرى ، لقد دفعت التزامات جديدة. # 9308

أيضًا إذا كان بإمكانك تقديم روابط للانضمام إلى قناة IRC أو قائمة Slack / gitter / mailing الخاصة بـ pdf.js.

@ روب - W هل ما زالت المشكلة قائمة؟ إذا كانت الإجابة بنعم ، أود العمل عليها.
شكرا لك.

المحاولة الأولى لهذا كانت في # 9308 ، لذا يمكنك استخدام ذلك كمصدر إلهام. دعونا نركز على الحصول على إصدار بسيط يعمل ، أي إصدار يعمل محليًا فقط. ليس من الضروري أن تعمل على الروبوتات أو Travis CI ؛ إذا تمكنا من إعداد تقارير التغطية محليًا فهذا أمر مهم بالفعل. محليًا ، سيكون من الجيد عمل أمر يسمى gulp coverage والذي يقوم بتشغيل اختبارات الوحدات المجهزة وينشئ تقرير تغطية بناءً على ذلك. إنه يعمل ودمج ، يمكننا دائمًا تكرار ذلك.

timvandermeij هل ما زالت نشطة؟ يمكنني أن أجربها أيضًا

نعم ، لا تتردد في العمل على هذا! يجب أن نبدأ بسيط. راجع https://github.com/mozilla/pdf.js/issues/8632#issuecomment -455868037 للتعرف على نهج محتمل.

timvandermeij أتساءل عما إذا كان بإمكاني إعطاء هذه اللقطة؟ سؤال واحد أكبر لدي هو ما إذا كان من الممكن استخدام برنامج نصي npm لإنشاء التقرير بدلاً من ذلك ، أو إذا كان يجب أن يكون مهمة gulp ؟

ليس لدي الكثير من الإلمام بـ gulp لكنني على استعداد لمعرفة ما إذا كان هذا مطلوبًا لذلك

لا أعتقد أن أي شخص يعمل على هذا ، لذا تفضل! من المهم أن تبقي الأمر بسيطًا بالنسبة للتصحيح الأولي. نظرًا لأننا نستخدم Gulp كأداة رئيسية لدينا ، فمن المفضل استخدام ذلك ، لكننا أيضًا منفتحون على اقتراحات أخرى. راجع https://github.com/mozilla/pdf.js/issues/8632#issuecomment -455868037 للحصول على أفكار التنفيذ. لا يتطلب الأمر خبرة كبيرة مع Gulp لأن Gulp عبارة عن عداء مهام بسيط إلى حد ما ، أي أنه غالبًا ما يلف أي شيء قد تفعله أيضًا في برنامج نصي NPM. ألق نظرة على Gulpfile للحصول على بعض الإلهام.

أود العمل على هذا. هل ما زالت القضية مفتوحة؟ وأين يمكنني الحصول على فهم أفضل للخلل؟

كان jezhou يعمل على هذا وقد أحرز بعض التقدم في # 11580. لم يتم تحديث العلاقات العامة مؤخرًا.

شكرا جزيلا على التحديث لك. أعتقد أنه يمكنني البدء في العمل عليها؟ أين
هل يمكنني الحصول على مزيد من المعلومات؟ عن الموضوع وبقية منه ؟؟

في يوم السبت ، 16 مايو 2020 ، الساعة 5:56 مساءً ، كتب Rob Wu ، [email protected] :

jezhou https://github.com/jezhou كان يعمل على هذا وقد صنع البعض
التقدم في # 11580 https://github.com/mozilla/pdf.js/pull/11580 . العلاقات العامة
لم يتم تحديثه مؤخرا رغم ذلك.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/mozilla/pdf.js/issues/8632#issuecomment-629637879 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AKUZ65CGSIZF6OMFZWENWF3RR2A77ANCNFSM4DSK7SGQ
.