Pdf.js: जनरेट (परीक्षण) कवरेज आँकड़े

unittestcli - पीडीएफ की कुछ इकाई परीक्षण चलाता है। Node.js में PDF.js (न्यूनतम स्रोत परिवर्तन के साथ, केवल बेबल के साथ वाष्पोत्सर्जन के साथ)।
Browsertest - ब्राउज़र में परीक्षण चलाता है (हम क्रोम और फ़ायरफ़ॉक्स का परीक्षण करते हैं)। यह generic बिल्ड टारगेट द्वारा बनाए गए बाइनरी पर निर्भर करता है, जो बबेल के साथ कोड किए गए कोड का उपयोग करता है और फिर वेबपैक के साथ बंडल किया जाता है।

ध्यान दें कि browsertest संदर्भ परीक्षण चलाएंगे, वहीं unittest कमांड भी है जो ब्राउज़र में यूनिट परीक्षणों का पूरा सेट चलाता है (जैसा कि unittestcli विपरीत है जो केवल एक सबसेट चलाता है की मौजूदा इकाई-परीक्षण)।

इसके अलावा, ध्यान दें कि "बाबेल के साथ वाष्पोत्सर्जन" कदम को छोड़ दिया जा सकता है, अगर PDFJS_NEXT बिल्ड ध्वज सेट किया जाता है (या तो gulpfile.js , या कमांड-लाइन तर्क के रूप में अन्य बिल्ड फ़्लैग)। जबकि कोड अभी भी वेबपैक के साथ बंडल है, कम से कम ट्रांसप्लसेंट चरण से बचना संभव है।

@ रोब - WI इस पर काम करना चाहेंगे

यह तुम्हारा है! अगर आपको सवाल हैं तो हमें बताएं (अधिमानतः आईआरसी पर)।

@timvandermeij मैं कर्मा

कर्म का उपयोग करके मुझे परीक्षण रिपोर्ट मिली https://drive.google.com/file/d/0ByddvU1PKkWaWEZTWHFYT0Y0aTg/view?usp=sharing
लेकिन टेस्ट कवरेज के आँकड़े https://drive.google.com/file/d/0ByddvU1PKkWaS1ZiT1dobU1DQUk/view?usp=sharing नहीं दिखाए जा रहे हैं

@ Divya063 क्या आप अपना कोड साझा कर सकते हैं, उदाहरण के लिए अपने वर्तमान कोड को अपने PDF.js पर Github पर कांटा लगाकर? मुझे आश्चर्य है कि क्या आवश्यक होने पर वेबपैक या बैबल चलाया जा रहा है।

और Node.js के कौन से संस्करण का उपयोग कर रहे हैं?

प्रतिक्रिया के लिए धन्यवाद, नोड संस्करण 6.11.1 है। यहां शाखा https://github.com/Divya063/pdf.js/tree/dev का लिंक दिया गया है

त्रुटियाँ हैं:

फ़ायरफ़ॉक्स 43.0.0
SyntaxError: आयात घोषणाएं केवल शीर्ष स्तर पर दिखाई दे सकती हैं
क्रोम 60.0.3112
बिना पढ़ा हुआ वाक्यविन्यास: अप्रत्याशित टोकन आयात

यह इंगित करता है कि उपयोग से पहले कोड को ट्रांसप्लड नहीं किया गया है। वर्तमान में ईएस मॉड्यूल के लिए अंतर्निहित समर्थन किसी भी ब्राउज़र ( अधिक जानकारी ) में डिफ़ॉल्ट रूप से सक्षम नहीं है, इसलिए कोड को पहले ट्रांसप्लड करना होगा।

मैंने अपनी प्रारंभिक पोस्ट को यह इंगित करने के लिए संपादित किया है कि ट्रांसप्लीकेशन को PDF.js की बिल्ड सिस्टम में कहाँ कॉन्फ़िगर किया गया है। शायद आप istanbul और babel को एकीकृत करने के लिए मौजूदा प्लगइन का उपयोग करने का प्रयास कर सकते हैं। एक त्वरित खोज https://github.com/istanbuljs/babel-plugin-istanbul दिखाती है, लेकिन अन्य विकल्प भी हो सकते हैं।

(और फ़ायरफ़ॉक्स का वर्तमान स्थिर संस्करण 55 है। आप फ़ायरफ़ॉक्स 43 के साथ परीक्षण कर रहे थे, जो प्राचीन है और समर्थित नहीं है। मेरा सुझाव है कि आप फिर से परीक्षण करने से पहले फ़ायरफ़ॉक्स के हाल के संस्करण में अपग्रेड करें)

@ रोब - डब्ल्यू त्रुटियों को इंगित करने के लिए धन्यवाद। मैं परिणामों के साथ जल्द ही अपडेट करूंगा।

@ रोब - WI ने karma-browserify का उपयोग करके कोड ट्रांसप्लड किया और फ़ायरफ़ॉक्स संस्करण को अपग्रेड किया लेकिन अभी भी बहुत सारी त्रुटियां सामने आ रही हैं। यह शाखा की लिंक है https://github.com/Divya063/pdf.js/tree / dev

क्या आप त्रुटि संदेश साझा कर सकते हैं?

और यदि संभव हो, तो ब्राउज़र की बजाय वेबपैक का उपयोग करने का प्रयास करें, क्योंकि वेबपैक वह है जो हम पहले से ही उपयोग करते हैं। ऐसा करने से हम उस कोड को लिख सकते हैं जो वास्तव में ब्राउज़र में उपयोग किया जाता है।

और मैं यह भी देखता हूं कि आप .idea और अन्य उपयोगकर्ता-विशिष्ट प्रोजेक्ट / IDE फ़ाइलों की जाँच कर रहे हैं। जब आप किसी मौजूदा प्रोजेक्ट में योगदान करते हैं, तो असंबंधित फ़ाइलों को प्रोजेक्ट में शामिल नहीं करना बेहतर होता है, क्योंकि यह रिपॉजिटरी को अव्यवस्थित करता है और मर्ज टकराव का कारण बनता है। अंतिम पुल अनुरोध में, इन फ़ाइलों को शामिल नहीं किया जाना चाहिए।

क्या यह मुद्दा अभी भी है? अगर हां, तो मैं इस पर काम करना चाहूंगा।

हां, बेझिझक इस पर काम करें।

@timvandermeij
मैं इस पर काम कर रहा था। मैंने रिपोर्ट प्रदर्शित करने के लिए अपने परीक्षण और कवरॉल को कवर करने के लिए istanbul का उपयोग किया है। मैंने जहाँ भी आवश्यक आवश्यक परिवर्तन किए हैं। हालांकि, जब भी मैं कवरॉल का उपयोग करता हूं

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

थोड़ी सी Googling से ऐसा लगता है कि इस त्रुटि का अर्थ है कि coveralls lcov फॉर्मेट में डेटा नहीं मिल रहा है। आप जाँच सकते हैं कि क्या व्यक्तिगत npm run cover -- --report lcovonly && cat ./coverage/lcov.info | coveralls में वास्तव में आपके द्वारा अपेक्षित परिणाम लौटाते हैं।

@timvandermeij
वर्तमान में मुख्य समस्या यह कथन है
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 पर, ऐसा लगता है कि ये बहुत ही सामान्य त्रुटियाँ हैं। और त्रुटि मूल रूप से istanbul के साथ है। मैंने उसी के विभिन्न संस्करणों के बीच स्विच करने की कोशिश की लेकिन त्रुटि उत्पन्न होती रही। हालाँकि, सभी स्थानों पर परीक्षण मोचा द्वारा किया गया है, लिंट या अनइस्टेस्ट आदि द्वारा नहीं किया गया है और इस प्रकार अधिकांश (लगभग) संकल्प भी केवल मोचा के लिए हैं। ये कुछ स्रोत थे जिन्हें मैंने देखा

https://github.com/gotwarlost/istanbul/issues/262
https://github.com/coryhouse/react-slingshot/issues/245
https://github.com/gotwarlost/istanbul/issues/496
और कई अन्य भी लेकिन उनमें से किसी ने वास्तव में मदद नहीं की :(

बिल्ड ट्रैविस ( https://travis-ci.org/shikhar-scs/pdf.js/jobs/318422621 ) पर पारित हो जाता है, लेकिन फिर से कवरेज उत्पन्न नहीं होता है।

मुझे वास्तव में यकीन नहीं है कि ऐसा क्यों हो रहा है, लेकिन मुझे बहुत से लोग ऐसे भी मिले जिन्होंने इसे जैस्मीन के साथ सफलतापूर्वक किया, इसलिए यह संभव होना चाहिए। अगर आपके लिए https://bryce.fisher-fleig.org/blog/setting-up-istanbul-with-jasmine/index.html काम करता है? पहले केवल उन सटीक चरणों को देखें, जो यह देखते हैं कि क्या कार्य अकेले हैं, और फिर इसे पीडीएफ में एकीकृत करने का प्रयास करें।

इस पर
कवरेज रिपोर्टें अब अंततः उत्पन्न की जा रही हैं। हालाँकि मुझे ट्रांसपाइल की जरूरत है और फिर इंपोर्ट और एक्सपोर्ट स्टेटमेंट के साथ अपनी समस्याओं को दिखाने के लिए इसका परीक्षण करें
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 फाइल करूँगा।

@timvandermeij

यहाँ वे हैं: बिल्ड पासिंग और कवरेज के लिए कॉल करना ।

कवरेज की रिपोर्ट

हालाँकि, जैसा कि आयात और निर्यात विवरण मौजूद हैं, उन फ़ाइलों तक पहुंचने के बाद भी, वे पूरी तरह से परीक्षण करते हैं और इस प्रकार हमें 0% कवरेज रिपोर्ट मिल रही है। जहां तक ​​मुझे पता है कि मुझे चमेली परीक्षण से पहले इन फाइलों को ईएस 6 को बेबीलाइज़ करना होगा और यह एक समस्या साबित हो रही है। मैं चमेली को ES6 कोड कैसे प्रदान करूं?
क्या मैं यहाँ gjp फ़ाइल में परिवर्तन कर सकता हूँ जैसा कि यहाँ उल्लेख किया गया है http://jpsierens.com/use-es6-right-now/ ?

आप वास्तव में समाधान के करीब पहुंच रहे हैं। कवरेज रिपोर्टों से ऐसा लगता है कि आप lib फ़ाइलों पर कवरेज चलाते हैं, जिसे पहले से ही ES6 (https://github.com/mozilla/pdf.js/blob/6ac9b1c5ed5d0f567872b84827cccc9595bb2bg पर देखें)। js # L965 और https://github.com/mozilla/pdf.js/blob/6ac9e1c5ed0d5f067872b8482724c171c79566b2-gulpfile.js#L985)। या क्या यह समस्या है कि इकाई परीक्षण स्वयं ट्रांसप्लड नहीं हैं? मैं वास्तव में परिचित नहीं हूं कि यह कैसे ठीक से काम करता है, लेकिन अगर यूनिट परीक्षणों के लिए गुलफाइल के कुछ परिवर्तनों की तुलना में यह आवश्यक है।

@timvandermeij

या क्या यह समस्या है कि इकाई परीक्षण स्वयं ट्रांसप्लड नहीं हैं? मैं वास्तव में परिचित नहीं हूं कि यह कैसे ठीक से काम करता है, लेकिन अगर यूनिट परीक्षणों के लिए गुलफाइल के कुछ परिवर्तनों की तुलना में यह आवश्यक है।

समस्या यह थी कि मैं गलत फ़ोल्डर में परीक्षण चला रहा था। build>lib फ़ोल्डर में पहले से ही ES6 प्रारूप में पूरी परियोजना शामिल है और मैंने अब पूरी बात को सही कर दिया है अर्थात चमेली और कवरॉल का रास्ता।
एक अन्य समस्या --report lcovonly बयान थी। जादुई रूप से (मुझे सच में पता नहीं क्यों) जब मैंने इस हिस्से को कवरलैस लाइन से हटा दिया, तो रिपोर्टें उत्पन्न होनी शुरू हो गईं।शायद मुझे इस पर ध्यान देना चाहिए था

आप जाँच सकते हैं कि क्या npm रन कवर में व्यक्तिगत कमांड - --report lcovonly && cat ./coverage/lcov.info | वास्तव में coveralls आपके द्वारा अपेक्षित परिणाम लौटाते हैं।

इस बारे में बताने के लिए शुक्रिया।

अंत में, हम रिपोर्ट उत्पन्न करने में सक्षम हैं: टाडा: और हालांकि वे थोड़े उदास दिखते हैं लेकिन सटीक फाइलों को पढ़ने से आपको इसका कारण मिलेगा -

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
यह मेरी नवीनतम प्रतिबद्ध के लिए लिंक है।

रिपोर्ट के अलावा coveralls.io पर उत्पन्न नहीं किया जा रहा है सब कुछ ठीक है मुझे लगता है। तो क्या मैं एक पीआर उत्पन्न कर सकता हूं क्योंकि यह कई और लोगों का ध्यान आकर्षित करेगा और इस मुद्दे को पहले की बजाय हल कर सकता है?

अच्छा काम! कवरेज का अंदाजा लगाना वास्तव में अच्छा है और रिपोर्टें आखिरकार हमें यही देती हैं। वास्तव में यह स्पष्ट रूप से दिखाता है कि हमें बहुत अधिक इकाई परीक्षण की आवश्यकता है, लेकिन हमने हाल ही में इकाई परीक्षण के लिए जोड़े गए सभी तरीकों को वास्तव में रिपोर्ट में शामिल किया गया है, ताकि यह पूरी तरह से ठीक दिखाई दे।

मुझे आश्चर्य है कि अगर निर्मित फ़ाइलों के बजाय स्रोत फ़ाइलों पर कवरेज को चलाना संभव होगा। यह समझने में आसान बनाता है, क्योंकि अब http://pdfjscoveragereport.bitballoon.com/lib/display/metadata.js.html पर मैं देखता हूं कि लाइन 28 को कवर नहीं किया जा रहा है, जबकि यह हमारा कोड नहीं है, बल्कि स्वचालित रूप से उत्पन्न कोड है। यदि यह कठिन हो जाता है, तो हम वर्तमान दृष्टिकोण को पहले संस्करण के रूप में कर सकते हैं और अनुवर्ती समस्या में ऐसा कर सकते हैं।

तो क्या मैं एक पीआर उत्पन्न कर सकता हूं क्योंकि यह कई और लोगों का ध्यान आकर्षित करेगा और इस मुद्दे को पहले की बजाय हल कर सकता है?

हाँ यह एक अच्छा विचार है। फिर हम समीक्षा प्रक्रिया शुरू कर सकते हैं और देख सकते हैं कि किन मुद्दों को संबोधित करना बाकी है।

कवरेज का अंदाजा लगाना वास्तव में अच्छा है और रिपोर्टें आखिरकार हमें यही देती हैं। वास्तव में यह स्पष्ट रूप से दिखाता है कि हमें बहुत अधिक इकाई परीक्षण की आवश्यकता है, लेकिन हमने हाल ही में इकाई परीक्षण के लिए जोड़े गए सभी तरीकों को वास्तव में रिपोर्ट में शामिल किया गया है, ताकि यह पूरी तरह से ठीक दिखाई दे।

हालांकि यह निश्चित रूप से सच है कि हम बहुत अधिक यूनिट-परीक्षणों के साथ कर सकते हैं, कोड-बेस के बड़े हिस्से हैं जो शायद कभी भी अकेले यूनिट-परीक्षणों से "अच्छे" पर्याप्त परीक्षण-कवरेज के पास नहीं मिलेंगे।

जैसा कि https://github.com/mozilla/pdf.js/issues/8632#issue -241690851 में बताया गया है कि कुछ अलग-अलग टेस्ट-सूट हैं, और जब तक मैं गलत नहीं हूँ, तब तक gulp browsertest या

@ सफ़लुपुगस @timvandermeij

आज सुबह मैंने बड़े पैमाने पर सभी फ़ोल्डरों में कवरेज की रिपोर्ट को व्यक्तिगत रूप से 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 browsertest से कवरेज परिणाम प्राप्त करना वास्तव में हमारे वास्तविक परीक्षण-कवरेज जैसा दिखता है, यह जानने के लिए लगभग आवश्यक होगा।

@Snuffleupagus ये विशिष्ट परीक्षण कहाँ झूठ हैं? हम ऊपर वर्णित चमेली-नोड विवरण का उपयोग करके सीधे उन्हें परीक्षण करने का प्रयास कर सकते हैं।

यदि यह कठिन हो जाता है, तो हम वर्तमान दृष्टिकोण को पहले संस्करण के रूप में कर सकते हैं और अनुवर्ती समस्या में ऐसा कर सकते हैं।

हां, हम ऐसा कर सकते थे।

हाँ यह एक अच्छा विचार है। फिर हम समीक्षा प्रक्रिया शुरू कर सकते हैं और देख सकते हैं कि किन मुद्दों को संबोधित करना बाकी है।

ज़रूर, मैं इसके साथ शुरू करूँगा।

# 9308 पर पीआर ने केवल यूनिट परीक्षणों के लिए परीक्षण कवरेज का एक उदाहरण दिखाया है। उत्पन्न रिपोर्टें बहुत कम मूल्य प्रदान करती हैं क्योंकि यूनिट परीक्षणों का हमारा सेट बहुत छोटा है। अधिक जानकारी के लिए, https://github.com/mozilla/pdf.js/pull/9308#issuecomment -353588039 देखें

तो, ब्राउज़र परीक्षण प्राप्त करने के लिए, हमें आवश्यकता है:

1. कवरेज डेटा उत्पन्न करने का एक तरीका।
2. कवरेज डेटा को पुनः प्राप्त करने का एक तरीका (और इसे coveralls पर अपलोड करें)।

1) को संबोधित करने के लिए, gulpfile.js को वैकल्पिक रूप से कोड इंस्ट्रूमेंटेशन जोड़ने के लिए संपादित किया जाना चाहिए, जो एक ब्राउज़र में window.__coverage__ ऑब्जेक्ट को निर्यात किया जाता है। gulp-istanbul उपयोगी हो सकता है। प्रलेखन विरल लगता है, लेकिन मुझे https://stackoverflow.com/questions/38208735/no-window-coverage-object-is-created-by-istanbul-phantomjs पर एक उदाहरण मिला है

चरण 1 को समाप्त करने के बाद, ब्राउज़र परीक्षणों में window.__coverage__ चर होगा (या जो भी आपने coverageVariable कॉन्फ़िगरेशन पैरामीटर में रखा था)। कवरेज रिपोर्ट प्राप्त करने के लिए:

1. परीक्षण धावक (https://github.com/mozilla/pdf.js/blob/e081a708c36cb2aacff7889048863723fff23671/test/briver.js) को संशोधित करके XMLHttpRequest के साथ परीक्षण सर्वर पर कवरेज परिणाम पोस्ट करना होगा।
2. परीक्षण सर्वर में (https://github.com/mozilla/pdf.js/blob/e081a708c36cb2aacff788904886232323fff23671/test/test.js), परीक्षा परिणाम प्राप्त करने के लिए एक नया हुक पंजीकृत करें और fs का उपयोग करके एक फ़ाइल में लिखें।
3. रिपोर्ट को coveralls पर अपलोड करें (जैसे कि "coveralls" कमांड के साथ # 9308 में दिखाया गया है)।

@ रोब - डब्ल्यू इस तरह की एक विस्तृत समीक्षा के लिए धन्यवाद। मैं फॉलोअप करूंगा और जल्द से जल्द वापस लौटूंगा।

यह टिप्पणी कार्यान्वयन के लिए सुझाव देती है, और https://github.com/mozilla/pdf.js/pull/9308#issuecomment -353710595 से प्रश्नों को संबोधित करती है

istanbul केवल इंस्ट्रूमेंटेशन को कोड में जोड़ता है। इस इनपुट को निष्पादन योग्य कोड माना जाता है, क्योंकि "इंस्ट्रूमेंटेशन" का अर्थ अतिरिक्त जावास्क्रिप्ट कोड जोड़ना है जो निष्पादन का पता लगाता है जब निष्पादन उस लाइन, स्टेटमेंट, आदि से गुजरता है। यदि इंस्ट्रूमेंटेशन जोड़ने के बाद कोड को फिर से बदल दिया जाता है, तो परिणामी कवरेज रिपोर्ट अर्थहीन हो जाती है।

इस इंस्ट्रूमेंटेशन को प्रोग्राम चलाने के दौरान फ्लाई पर किया जा सकता है (जैसे जब आप कमांड लाइन से istanbul cover चलाते हैं, तो istanbul Node.js के require लिए कॉल इंटरसेप्ट करेंगे और मॉड्यूल लोड होने से पहले इंस्ट्रूमेंटेशन के साथ कोड को बदलना ), या निष्पादन से अलग किया जाता है (जैसे कि ब्लॉग पोस्ट प्रदर्शित करता है: इंस्ट्रूमेंट कोड कमांड लाइन पर उत्पन्न होता है, निष्पादन ब्राउज़र में किया जाता है)।

# 9308 पर आपके वर्तमान पीआर में, आप istanbul cover को jasmine चलाने के कार्यक्रम के रूप में आमंत्रित कर रहे हैं। जैसा कि मैंने पहले उल्लेख किया है, प्रभाव gulp unittestcli चलने के समान है - अर्थात परीक्षण build/lib निर्देशिका में एक पूर्व-निर्मित पुस्तकालय के विरुद्ध चलाए जाते हैं (यह test/unit/clitests.json में कॉन्फ़िगर किया गया है) । यह बताता है कि आपकी कवरेज रिपोर्ट build/lib/ को छोड़कर हर चीज़ के लिए 0 कवरेज क्यों दिखा रही है (क्योंकि केवल require -d (Node.js) मॉड्यूल build/lib और build/streams/ - gulp unittestcli कार्य परिभाषा का अंत देखें)।

उपयोगी कवरेज रिपोर्ट प्राप्त करने के लिए, कवरेज रिपोर्ट अधिमानतः एक मॉड्यूल स्तर पर होती है। यह एक कदम आगे है: आपको बिल्ड पाइपलाइन में istanbul को एकीकृत करने की आवश्यकता है, ताकि जब कोड ईएस 6 से ट्रांसपोंड हो, तो इंस्ट्रूमेंटेशन जोड़ा जाता है। उसके बाद, प्रति-मॉड्यूल रिपोर्ट उत्पन्न करना और अधिक कठिन हो जाता है (लेकिन असंभव नहीं है, सिद्धांत स्रोत मानचित्र में मूल फ़ाइलों को डेटा मैप करने के लिए पर्याप्त जानकारी प्रदान करते हैं)।
यह एक चुनौती है, और यह समझने की आवश्यकता है कि बैबेल, गल्प, इस्तानबुल और सोर्स मैप्स / मॉड्यूल का उपयोग कैसे किया जाए (मैंने पहले ही स्रोत कोड में प्रासंगिक स्थानों का उल्लेख किया है जहां पीडीएफ.जेएस पीडीएफ जेनरेट करने के लिए सभी मॉड्यूल को एक साथ लाता है। पुस्तकालय - # 8632 देखें)। यह ज्ञान बहुत उपयोगी है, इसलिए यदि आप चुनौतियों से डरते नहीं हैं, तो आप मेरे मार्गदर्शन में इसका पता लगा सकते हैं।

लेकिन इतनी गहराई से गोता लगाने से पहले, आइए कुछ सरल से शुरू करें: ब्राउज़र से कवरेज रिपोर्ट प्राप्त करना। हमारे पास ब्राउज़र में परीक्षण चलाने के दो तरीके हैं, unittest और browsertest । चूँकि हमारे पास Node.js में इकाई परीक्षणों को चलाने का पहले से ही आसान तरीका है, इसलिए हम browsertest पर ध्यान केंद्रित करते हैं। ब्राउज़र परीक्षण व्यक्तिगत मॉड्यूल का उपयोग नहीं करते हैं, लेकिन generic gulp लक्ष्य , GENERIC_DIR , aka build/generic/ बनाए गए PDF.js लाइब्रेरी का। तो यह 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 लोड करना होगा कुछ कॉन्फ़िगरेशन पैरामीटर के आधार पर

एक बार जब आप सामान्य pdf.js लाइब्रेरी को इंस्ट्रूमेंट pdf.js लाइब्रेरी से बदल देते हैं, तो कवरेज आँकड़े परीक्षण रन के रूप में उत्पन्न हो जाएंगे। परिणाम वैश्विक window.__coverage__ चर में संग्रहीत किया जाता है। जब इन-ब्राउज़र टेस्ट ड्राइवर समाप्त हो जाता है ( टेस्ट / ड्राइवर.जेएस में _quit विधि ), तो आप इस रिपोर्ट को क्रमबद्ध कर सकते हैं (जैसे JSON.stringify(window.__coverage__) का उपयोग करके) और इसे XMLHttpRequest साथ सर्वर पर भेजें driver.js फ़ाइल में अन्य स्थान देखें - सुनिश्चित करें कि आप सर्वर को रिपोर्ट भेजेंगे /tellMeToQuit संदेश भेजने से पहले, अन्यथा कवरेज रिपोर्ट प्रेषित नहीं हो सकती है सही ढंग से)।
आप अपने नए कस्टम एपीआई कॉल के लिए https://github.com/mozilla/pdf.js/blob/ba5dbc96326518ad716158ef040f61794cc72202/test/test.js में एक नया हैंडलर जोड़ सकते हैं। कोड उदाहरणों के लिए, XMLHttpRequest कॉल driver.js (जैसे /tellMeToQuit संदेश) में देखें, और test.js में संबंधित हैंडलर ढूंढें। एक बार जब आप सर्वर की ओर से क्रमबद्ध JSON प्राप्त कर लेते हैं, तो किसी फ़ाइल में कवरेज रिपोर्ट लिखने के लिए fs.writeFileSync API का उपयोग करें (फिर से test.js में अन्य उदाहरण हैं जो दिखाता है कि आप फ़ाइलों को कैसे लिख सकते हैं) ।

@ रोब - डब्ल्यू मैं वर्तमान में नए साल तक उपलब्ध नहीं हूं ... मैं उसके बाद सुनिश्चित करने के लिए पकड़ लूंगा

ऐसा करने के बाद, आपको परीक्षण / test_slave.html को बिना शर्त लोड नहीं करने की आवश्यकता है ../build/generic/build/pdf.js

ऐसा करने के बाद, आपको परीक्षण / test_slave.html को बिना शर्त लोड नहीं करने की आवश्यकता है ../build/generic/build/pdf.js

@ रोब - WI ने tests.js (TestFilter पैरामीटर की नकल करके) में एक समान पैरामीटर बनाने का प्रबंधन किया, हालांकि, test/test_slave.html में इसे शामिल करना मेरे लिए अभी भी एक संभावना है। बाकी बदलावों के लिए कृपया फिर से पीआर पर जाएँ, मैंने नए कमिट्स को आगे बढ़ाया है। # 9308

इसके अलावा अगर आप मुझे IRC चैनल में शामिल होने के लिए लिंक दे सकते हैं या pdf.js के लिए विशेष रूप से सुस्त / मेलिंग सूची दे सकते हैं।

@ रोब - डब्ल्यू क्या अभी भी समस्या है? अगर हां, तो मैं इस पर काम करना चाहूंगा।
धन्यवाद।

इसके लिए पहला प्रयास # 9308 में है, इसलिए आप इसे प्रेरणा के रूप में उपयोग कर सकते हैं। आइए एक न्यूनतम संस्करण पर काम करने पर ध्यान केंद्रित करें, अर्थात, जो केवल स्थानीय स्तर पर काम करता है। यह बॉट्स या ट्रैविस सीआई पर काम नहीं करता है; अगर हम स्थानीय स्तर पर कवरेज रिपोर्ट बना सकते हैं जो पहले से ही बहुत महत्वपूर्ण है। स्थानीय स्तर पर, gulp coverage नामक एक कमांड बनाना अच्छा होगा जो इंस्ट्रूमेंटेड यूनिट टेस्ट चलाता है और उसी के आधार पर एक कवरेज रिपोर्ट तैयार करता है। यह काम कर रहा है और विलय कर रहा है, हम हमेशा उस पर पुनरावृत्ति कर सकते हैं।

@timvandermeij क्या यह अभी भी सक्रिय है? मैं इसे एक बार भी दे सकता हूं

हाँ, इस पर काम करने के लिए स्वतंत्र महसूस करें! हमें सरल शुरुआत करनी चाहिए; संभावित दृष्टिकोण के लिए https://github.com/mozilla/pdf.js/issues/8632#issuecomment -455868037 देखें।

@timvandermeij सोच रहा था कि क्या मैं इसे शॉट दे सकता हूं? मेरे पास एक बड़ा सवाल यह है कि क्या रिपोर्ट तैयार करने के लिए एक npm स्क्रिप्ट का उपयोग करना संभव है, या यदि उसे gulp कार्य करना है?

मेरे पास gulp साथ बहुत अधिक परिचित नहीं है, लेकिन मैं इसके लिए आवश्यकता होने पर सीखने के लिए तैयार हूं

मुझे नहीं लगता कि कोई भी इस पर काम कर रहा है, इसलिए आगे बढ़ें! प्रारंभिक पैच के लिए इसे सरल रखना महत्वपूर्ण है। चूंकि हम अपने मुख्य टूलींग के रूप में गुल्प का उपयोग करते हैं, इसलिए इसका उपयोग करना पसंद किया जाता है, लेकिन हम अन्य सुझावों के लिए भी खुले हैं। कार्यान्वयन विचारों के लिए https://github.com/mozilla/pdf.js/issues/8632#issuecomment -455868037 देखें। हालांकि इसे गुल के साथ अधिक अनुभव की आवश्यकता नहीं है क्योंकि गुलप काफी सरल कार्य धावक है, अर्थात, यह ज्यादातर कुछ भी लपेटता है जिसे आप एनपीएम स्क्रिप्ट में भी करेंगे। कुछ प्रेरणा पाने के लिए गुलफ़िले पर नज़र डालें।

मैं इस पर काम करना चाहूंगा। क्या मुद्दा अभी भी खुला है? और मुझे बग की बेहतर समझ कहां से मिल सकती है?

@ जेजू इस पर काम कर रहा था और # 11580 में कुछ प्रगति की है। PR को हाल ही में अपडेट नहीं किया गया है।

अपडेट के लिए बहुत बहुत धन्यवाद। मुझे लगता है कि मैं इस पर काम शुरू कर सकता हूं? कहाँ पे
क्या मुझे और जानकारी मिल सकती है? इस मुद्दे और बाकी के बारे में ??

सत पर, 16 मई 2020, शाम 5:56 बजे रॉब वू, सूचनाएं @github.com ने लिखा:

@ जेजो https://github.com/jezhou इस पर काम कर रहा था और उसने कुछ बनाया है
# 11580 में प्रगति https://github.com/mozilla/pdf.js/pull/11580 जनसंपर्क
हालांकि हाल ही में अपडेट नहीं किया गया है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/mozilla/pdf.js/issues/8632#issuecomment-62963799 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AKUZ65CGSIZF6OMFZWENWF3RR2A77ANCNFSM4DSK7SGQ
।