Pdf.js: Hasilkan (uji) statistik cakupan

unittestcli - Menjalankan beberapa pengujian unit PDF.js di Node.js (dengan perubahan sumber minimal, hanya dengan transpilasi dengan babel).
browsertest - Menjalankan pengujian di browser (kami menguji Chrome dan Firefox). Ini bergantung pada biner yang dibuat oleh target build generic , yang menggunakan kode ditranspilasi dengan babel dan kemudian dibundel dengan webpack.

Perhatikan bahwa sementara browsertest akan menjalankan tes referensi , ada juga perintah unittest yang menjalankan set lengkap tes unit di browser (sebagai lawan dari unittestcli yang hanya menjalankan subset dari unit-test yang ada).

Lebih lanjut, perhatikan bahwa langkah "transpilasi dengan Babel" dapat dilewati, jika flag PDFJS_NEXT build disetel (seperti flag build lain di gulpfile.js , atau sebagai argumen baris perintah). Meskipun kode masih dibundel dengan Webpack, setidaknya langkah transpilasi dapat dihindari.

@ Rob - WI ingin mengerjakan ini

Itu milikmu! Beri tahu kami (sebaiknya di IRC) jika Anda memiliki pertanyaan.

@timvandermeij Saya berpikir untuk menggunakan alat Karma. Ini bekerja dengan mesin cakupan kode istanbul. Statistik dapat diperiksa untuk pelaksanaan tes, laporan HTML dapat dibuat darinya. Apakah ini cara yang baik untuk memulai?

Menggunakan Karma, saya mendapat laporan pengujian https://drive.google.com/file/d/0ByddvU1PKkWaWEZTWHFYT0Y0aTg/view?usp=sharing
tetapi statistik cakupan pengujian tidak ditampilkan https://drive.google.com/file/d/0ByddvU1PKkWaS1ZiT1dobU1DQUk/view?usp=sharing

@ Divya063 Dapatkah Anda membagikan kode Anda, misalnya dengan mendorong kode Anda saat ini ke cabang di garpu pdf.js Anda di Github? Saya bertanya-tanya apakah webpack atau babel sedang dijalankan saat diperlukan.

Dan versi Node.js mana yang Anda gunakan?

Terima kasih atas tanggapannya, versi Node adalah 6.11.1. Berikut ini tautan ke cabang https://github.com/Divya063/pdf.js/tree/dev

Kesalahannya adalah:

Firefox 43.0.0
SyntaxError: deklarasi impor hanya dapat muncul di tingkat atas
Chrome 60.0.3112
SyntaxError Tidak Tertangkap: Impor token tidak terduga

Ini menunjukkan bahwa kode tidak ditranspilasi sebelum digunakan. Saat ini ada dukungan built-in untuk modul ES tidak diaktifkan secara default di browser manapun ( info lebih lanjut ), jadi kode perlu ditranspilasi terlebih dahulu.

Saya telah mengedit posting awal saya untuk menunjukkan di mana transpilasi dikonfigurasi dalam sistem build PDF.js. Mungkin Anda bisa mencoba menggunakan plugin yang sudah ada untuk mengintegrasikan istanbul dan babel. Pencarian cepat menunjukkan https://github.com/istanbuljs/babel-plugin-istanbul , tetapi mungkin ada opsi lain juga.

(dan versi stabil Firefox saat ini adalah 55. Anda menguji dengan Firefox 43, yang kuno dan tidak didukung. Saya sarankan Anda meningkatkan ke versi terbaru Firefox sebelum menguji lagi)

@ Rob - W Terima kasih telah menunjukkan kesalahan. Saya akan segera memperbarui hasilnya.

@ Rob - WI mentranspilasi kode menggunakan karma-browserify dan meningkatkan versi firefox tetapi masih banyak kesalahan yang muncul. Berikut ini tautan cabang https://github.com/Divya063/pdf.js/tree / dev

Bisakah Anda membagikan pesan kesalahan?

Dan jika memungkinkan, coba gunakan webpack daripada browserify, karena webpack adalah yang sudah kita gunakan. Melakukannya memungkinkan kami untuk melengkapi kode yang sebenarnya digunakan di browser.

Dan saya juga melihat bahwa Anda memeriksa dalam .idea dan file proyek / IDE khusus pengguna lainnya. Saat Anda berkontribusi ke proyek yang sudah ada, lebih baik tidak menambahkan file yang tidak terkait ke proyek, karena itu mengacaukan repositori dan menyebabkan konflik penggabungan. Dalam permintaan penarikan terakhir, file-file ini tidak boleh disertakan.

Apakah masalah ini masih berlanjut? Jika ya, saya ingin mengerjakannya.

Ya, silakan mengerjakan ini.

@tokopedia
Saya sedang mengerjakan ini. Saya telah menggunakan istanbul untuk menutupi tes dan baju saya untuk menampilkan laporan. Saya telah membuat perubahan yang diperlukan di mana pun diperlukan. Namun, setiap kali saya menjalankan baju menggunakan

npm run coveralls

Saya mendapatkan kesalahan berikut

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

Saya mencoba mencari ini di sini dan di sini tetapi tidak berhasil. Ada bantuan tentang apa masalahnya?

Sulit untuk mengatakannya tanpa melihat kodenya. Bisakah Anda memasukkan kode ke cabang sehingga kontributor di sini dapat melihat bersama Anda?

@timvandermeij sini itu. Harap abaikan file permata. saya sudah menghapusnya.

Ada komentar @timvandermeij

Dari sedikit Googling, sepertinya kesalahan ini berarti coveralls tidak mendapatkan data dalam format lcov . Anda dapat memeriksa apakah masing-masing perintah di npm run cover -- --report lcovonly && cat ./coverage/lcov.info | coveralls ternyata mengembalikan hasil yang Anda harapkan.

@tokopedia
Masalah utama saat ini adalah pernyataan ini
No coverage information was collected, exit without writing coverage information
Oleh karena itu, file lcov selalu kosong dan ini terjadi

[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'

Saat googling, tampaknya ini adalah kesalahan yang sangat umum. dan kesalahan pada dasarnya terletak pada istanbul. Saya mencoba beralih di antara versi yang berbeda dari yang sama tetapi kesalahan terus terjadi. Namun, di semua tempat pengujian telah dilakukan dengan mocha dan bukan dengan serat atau unittest dll. Dan dengan demikian sebagian besar (hampir) resolusi juga hanya untuk mocha. Ini adalah beberapa sumber yang saya cari

https://github.com/gotwarlost/istanbul/issues/262
https://github.com/coryhouse/react-slingshot/issues/245
https://github.com/gotwarlost/istanbul/issues/496
dan beberapa lainnya juga, tetapi tidak ada yang benar-benar membantu :(

Build diteruskan ke travis ( https://travis-ci.org/shikhar-scs/pdf.js/jobs/318422621 ) tetapi sekali lagi cakupannya tidak dibuat.

Saya tidak begitu yakin mengapa itu terjadi, tetapi saya juga menemukan banyak orang yang berhasil melakukannya dengan Jasmine, jadi itu pasti mungkin. Bisakah Anda mencoba jika https://bryce.fisher-fleig.org/blog/setting-up-istanbul-with-jasmine/index.html cocok untuk Anda? Pertama, coba saja langkah-langkah tepat tersebut untuk melihat apakah berfungsi berdiri sendiri, lalu coba mengintegrasikannya ke PDF.js.

@timvandermeij di atasnya
Laporan cakupan akhirnya sekarang dibuat. Namun saya perlu transparan dan kemudian menguji karena muncul masalah dengan pernyataan impor dan ekspor
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)
Kesalahan ini muncul dengan setiap file js dan saya akan mengerjakannya dan segera mengajukan PR.

@tokopedia

Ini dia: build passing dan panggilan untuk cakupan .

Laporan liputan

Namun, karena pernyataan impor dan ekspor ada, bahkan setelah mencapai file-file itu, mereka belum sepenuhnya diuji dan dengan demikian kami mendapatkan laporan cakupan 0%. Sejauh yang saya tahu, saya perlu memberi label pada file-file ini ke ES6 sebelum pengujian melati dan itu terbukti menjadi masalah. Bagaimana cara memberikan kode ES6 ke jasmine?
Dapatkah saya membuat perubahan pada file gulp seperti yang disebutkan di sini http://jpsierens.com/use-es6-right-now/ ?

Anda memang semakin mendekati solusi. Dari laporan cakupan, sepertinya Anda menjalankan cakupan pada file lib , yang seharusnya sudah ditranspilasi ke ES6 (lihat https://github.com/mozilla/pdf.js/blob/6ac9e1c5ed0d5f067872b8482724c171c79566b2/gulpfile. js # L965 dan https://github.com/mozilla/pdf.js/blob/6ac9e1c5ed0d5f067872b8482724c171c79566b2/gulpfile.js#L985). Atau apakah masalah pengujian unit itu sendiri tidak terungkap? Saya tidak terlalu paham dengan cara kerjanya, tetapi jika itu yang terjadi maka beberapa perubahan pada Gulpfile untuk pengujian unit mungkin diperlukan.

@tokopedia

Atau apakah masalah pengujian unit itu sendiri tidak terungkap? Saya tidak terlalu paham dengan cara kerjanya, tetapi jika itu yang terjadi maka beberapa perubahan pada Gulpfile untuk pengujian unit mungkin diperlukan.

Masalahnya adalah saya menjalankan tes di folder yang salah. build>lib folder sudah berisi seluruh proyek dalam format ES6 dan saya sekarang telah mengoreksi semuanya yaitu jalur melati dan baju kerja.
Masalah lainnya adalah pernyataan --report lcovonly . Secara ajaib (saya benar-benar tidak tahu mengapa) ketika saya menghapus bagian ini dari garis baju, laporan mulai dihasilkan. Mungkin saya seharusnya lebih memperhatikan

Anda dapat memeriksa apakah perintah individu di npm run cover - --report lcovonly && cat ./coverage/lcov.info | baju dalam kenyataannya mengembalikan hasil yang Anda harapkan.

Terima kasih telah menunjukkan hal ini.

Akhirnya, kami dapat menghasilkan laporan: tada: dan meskipun terlihat agak menyedihkan tetapi membaca file yang tepat akan memberi Anda alasan mengapa -

1. Semua pernyataan bersyarat yang tidak dijalankan akan dihitung sebagai 'tidak tercakup'.
2. Semua pernyataan penugasan yang tidak dijalankan juga dihitung sebagai 'tidak tercakup'.

Saya jelas belum mengunggah laporan yang dihasilkan sendiri tetapi telah menghostingnya di tautan di sini http://pdfjscoveragereport.bitballoon.com . Silakan kunjungi tautan ini dan Anda akan mendapatkan laporan persis seperti yang diharapkan.

Namun hasil ini tidak tercermin pada coveralls.io : cry: Saya tidak tahu mengapa. Juga, saya telah memperhatikan bahwa bahkan setelah melakukan beberapa kali coveralls masih membangun proyek saya berdasarkan komitmen yang sangat lama dan bukan pada yang terbaru karena cakupannya di sana, meskipun dihasilkan, tetapi selalu tetap 0 ( meskipun sekarang bukan 0). Tolong bantu saya tentang cara mengatasinya.

Tapi tetap npm run coveralls akan memberikan seluruh laporan pertanggungan dalam format ini yang terletak di folder build/lib/coverage/lcov-report .

Saya harap semua ini akhirnya membantu, meskipun, masalah terakhir kami adalah menunjukkan laporan ini entah bagaimana pada baju.

Ini adalah link untuk build terbaru saya. https://travis-ci.org/shikhar-scs/pdf.js
Ini adalah link untuk commit terbaru saya.

Terlepas dari laporan yang tidak dibuat pada coveralls.io semuanya baik-baik saja, kurasa. Jadi, haruskah saya menghasilkan PR karena akan menarik perhatian lebih banyak orang dan mungkin menyelesaikan masalah ini lebih awal?

Kerja bagus! Sangat bagus untuk memiliki gagasan tentang liputan dan laporan akhirnya memberi kami itu. Memang hal ini dengan jelas menunjukkan bahwa kami memerlukan lebih banyak pengujian unit, tetapi semua metode yang baru-baru ini kami tambahkan untuk pengujian unit memang ditampilkan seperti yang tercakup dalam laporan, sehingga terlihat sangat baik.

Saya bertanya-tanya apakah mungkin untuk menjalankan cakupan atas file sumber daripada file yang dibangun. Itu membuatnya lebih mudah untuk dipahami, karena sekarang di http://pdfjscoveragereport.bitballoon.com/lib/display/metadata.js.html saya melihat baris 28 tidak tercakup padahal itu bukan kode kami, melainkan kode yang dibuat secara otomatis. Jika ternyata sulit, kita bisa melakukan pendekatan saat ini sebagai versi pertama dan melakukan ini dalam masalah tindak lanjut.

Jadi, haruskah saya menghasilkan PR karena akan menarik perhatian lebih banyak orang dan mungkin menyelesaikan masalah ini lebih awal?

Ya, itu ide bagus. Kami kemudian dapat memulai proses peninjauan dan melihat masalah mana yang harus ditangani.

Sangat bagus untuk memiliki gagasan tentang liputan dan laporan akhirnya memberi kami itu. Memang hal ini dengan jelas menunjukkan bahwa kami memerlukan lebih banyak pengujian unit, tetapi semua metode yang baru-baru ini kami tambahkan untuk pengujian unit memang ditampilkan seperti yang tercakup dalam laporan, sehingga terlihat sangat baik.

Meskipun memang benar bahwa kita dapat melakukan lebih banyak unit-test, sayangnya ada sebagian besar basis kode yang mungkin tidak akan pernah mendekati cakupan pengujian yang cukup "baik" hanya dari unit-test saja.

Seperti disebutkan di https://github.com/mozilla/pdf.js/issues/8632#issue -241690851 ada beberapa rangkaian pengujian yang berbeda, dan kecuali saya salah mendapatkan hasil cakupan dari gulp browsertest juga akan sangat penting untuk benar-benar mengetahui seperti apa cakupan tes kami yang sebenarnya.

@Snuffleupagus @timvandermeij

Pagi ini saya secara ekstensif mencoba mencari laporan cakupan di semua folder secara individual menggunakan pernyataan cd build && cd lib && istanbul cover --include-all-sources jasmine-node test , mengubah direktori yang berbeda menggunakan cd <directory name> dan menguji menggunakan jasmine-node <directory names and js files> tetapi sia-sia.

Meskipun laporan pengujian dibuat pada waktu tertentu (tidak selalu), hal ini terjadi karena satu atau dua file js format ES6 yang terletak di direktori tertentu (yang hanya membawa <2 ~ 3% dari laporan cakupan). Sayangnya, file js apa pun yang berisi import or export statements mengembalikan kesalahan dalam format ini.

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

Dan dengan kesalahan ini, file tidak diperiksa cakupannya sama sekali dan dengan demikian mengembalikan laporan 0%.

Saya bertanya-tanya apakah mungkin untuk menjalankan cakupan atas file sumber daripada file yang dibangun.

Sekali lagi, folder sumber berisi file yang memiliki pernyataan impor dan ekspor dan oleh karena itu kesalahan di atas terjadi karena file terkait tidak diperiksa sama sekali, yang mengarah ke cakupan 0%.

Oleh karena itu, sangat penting bagi kami untuk menguji dalam folder build itu sendiri.

mendapatkan hasil cakupan dari gulp browsertest juga akan sangat penting untuk benar-benar mengetahui seperti apa cakupan pengujian kami yang sebenarnya.

@Snuffleupagus Di manakah

Jika ternyata sulit, kita bisa melakukan pendekatan saat ini sebagai versi pertama dan melakukan ini dalam masalah tindak lanjut.

Ya, kita lebih baik melakukan itu.

Ya, itu ide bagus. Kami kemudian dapat memulai proses peninjauan dan melihat masalah mana yang harus ditangani.

Oke, saya akan mulai dengan itu.

PR di # 9308 telah menunjukkan contoh cakupan tes hanya untuk tes unit. Laporan yang dihasilkan memberikan sedikit nilai karena rangkaian pengujian unit kami sangat kecil. Untuk detail lebih lanjut, lihat https://github.com/mozilla/pdf.js/pull/9308#issuecomment -353588039

Jadi, untuk mendapatkan pengujian browser, kita membutuhkan:

1. Sebuah cara untuk menghasilkan data cakupan.
2. Sebuah cara untuk mengambil data cakupan (dan mengunggahnya ke baju-baju).

Ke alamat 1), gulpfile.js harus diedit untuk menambahkan instrumentasi kode, yang diekspor ke objek window.__coverage__ di browser. gulp-istanbul mungkin berguna. Dokumentasi tampaknya jarang, tetapi saya telah menemukan contohnya di https://stackoverflow.com/questions/38208735/no-window-coverage-object-is-created-by-istanbul-phantomjs. Kami TIDAK menggunakan PhantomJS, tetapi Anda dapat membaca pertanyaan, jawaban, dan posting blog yang ditautkan untuk memperdalam pemahaman Anda tentang cara kerja semuanya.

Setelah menyelesaikan langkah 1, pengujian browser akan memiliki variabel window.__coverage__ (atau apa pun yang Anda masukkan ke dalam parameter konfigurasi coverageVariable ). Untuk mendapatkan laporan cakupan:

1. Ubah runner pengujian (https://github.com/mozilla/pdf.js/blob/e081a708c36cb2aacff7889048863723fcf23671/test/driver.js) untuk memposting hasil cakupan dengan XMLHttpRequest ke server pengujian.
2. Di server pengujian (https://github.com/mozilla/pdf.js/blob/e081a708c36cb2aacff7889048863723fcf23671/test/test.js), daftarkan hook baru untuk menerima hasil pengujian, dan tulis ke file menggunakan fs Node.js API (mungkin setelah beberapa pasca-pemrosesan, seperti mengonversinya ke format lcov jika diperlukan).
3. Unggah laporan ke baju (mis. Dengan perintah "baju" seperti yang ditunjukkan pada # 9308).

@ Rob - W Terima kasih atas ulasan yang mendetail. Saya akan menindaklanjuti dan kembali secepat mungkin.

Komentar ini menawarkan tip untuk implementasi, dan menjawab pertanyaan dari https://github.com/mozilla/pdf.js/pull/9308#issuecomment -353710595

istanbul hanya menambahkan instrumentasi ke kode. Masukan ini seharusnya merupakan kode yang dapat dieksekusi, karena "instrumentasi" berarti menambahkan kode JavaScript tambahan yang mendeteksi saat eksekusi melewati baris tersebut, pernyataan, dll. Jika kode diubah lagi secara signifikan setelah menambahkan instrumentasi, laporan cakupan yang dihasilkan menjadi tidak berarti.

Instrumentasi ini dapat dilakukan dengan cepat saat program sedang dijalankan (mis. Saat Anda menjalankan istanbul cover dari baris perintah, istanbul akan mencegat panggilan ke require Node.js dan ubah kode dengan instrumentasi sebelum modul dimuat ), atau secara terpisah dari eksekusi (mis. seperti yang ditunjukkan postingan blog: kode berinstrumen dibuat pada baris perintah, eksekusi dilakukan di browser).

Dalam PR Anda saat ini di # 9308, Anda meminta istanbul cover dengan jasmine sebagai program yang akan dijalankan. Seperti yang saya sebutkan sebelumnya, efeknya mirip dengan menjalankan gulp unittestcli - yaitu pengujian dijalankan terhadap pustaka yang dibuat sebelumnya di direktori build/lib (ini dikonfigurasi dalam test/unit/clitests.json ) . Ini menjelaskan mengapa laporan cakupan Anda menunjukkan 0 cakupan untuk semuanya kecuali build/lib/ (karena satu-satunya modul require -d (Node.js) ada di build/lib dan build/streams/ - lihat akhir dari definisi tugas gulp unittestcli ).

Untuk mendapatkan laporan cakupan yang berguna , laporan cakupan sebaiknya pada tingkat modul. Ini adalah langkah ke depan: Anda perlu mengintegrasikan istanbul dalam pipeline build, sehingga ketika kode ditranspilasi dari ES6, instrumentasi ditambahkan. Setelah itu, menjadi lebih sulit untuk menghasilkan laporan per modul (tetapi bukan tidak mungkin, dalam peta sumber teori memberikan informasi yang cukup untuk memetakan data ke file asli).
Ini adalah tantangan, dan membutuhkan pemahaman yang baik tentang cara menggunakan Babel, gulp, istanbul dan peta / modul sumber (Saya sudah merujuk ke tempat-tempat yang relevan di kode sumber di mana PDF.js menyatukan semua modul untuk menghasilkan PDF.js perpustakaan - lihat # 8632). Pengetahuan ini sangat berguna, jadi jika Anda tidak takut dengan tantangan, Anda dapat mengeksplorasi ini di bawah bimbingan saya.

Namun sebelum menyelami lebih dalam, mari kita mulai dengan sesuatu yang lebih sederhana: mendapatkan laporan cakupan dari browser. Kami memiliki dua cara menjalankan pengujian di browser, unittest dan browsertest . Karena kita sudah memiliki cara yang cukup mudah untuk menjalankan pengujian unit di Node.js, mari kita fokus pada browsertest . Tes browser tidak menggunakan modul individual, tetapi pustaka PDF.js dibuat oleh target generic gulp , dalam GENERIC_DIR , alias build/generic/ . Jadi cukup menambahkan instrumentasi kode ke build/generic . Saya sarankan untuk mengambil build/generic/ sebagai direktori input, dan menulis hasilnya ke coverage/build/generic .

Setelah melakukan itu, Anda perlu mengubah test/test_slave.html untuk tidak memuat ../build/generic/build/pdf.js tanpa syarat dalam tag <script> , tetapi memuat secara bersyarat ../build/generic/build/pdf.js atau ../coverage/build/generic/build/pdf.js tergantung pada beberapa parameter konfigurasi (untuk pengujian Anda cukup meng-hard-code URL yang terakhir, sangat mudah untuk mengubah parameter hard-code ini nanti setelah Anda menyelesaikan tugas yang lebih sulit untuk mengirim laporan cakupan kembali ke server pengujian) .

Setelah Anda mengganti pustaka pdf.js normal dengan pustaka pdf.js berinstrumen, statistik cakupan akan dibuat saat pengujian dijalankan. Hasilnya disimpan dalam variabel window.__coverage__ global. Ketika test driver dalam browser selesai ( metode _quit di test / driver.js ), Anda dapat membuat serial laporan ini (misalnya menggunakan JSON.stringify(window.__coverage__) ) dan mengirimkannya ke server dengan XMLHttpRequest (lihat lokasi lain di file driver.js sebagai contoh - pastikan bahwa Anda mengirim laporan ke server SEBELUM mengirim pesan /tellMeToQuit , atau laporan cakupan mungkin tidak dikirim benar).
Anda dapat menambahkan penangan baru untuk panggilan API khusus baru Anda di https://github.com/mozilla/pdf.js/blob/ba5dbc96326518ad716158ef040f61794cc72202/test/test.js . Untuk contoh kode, lihat XMLHttpRequest panggilan di driver.js (seperti pesan /tellMeToQuit ), dan temukan penangan yang sesuai di test.js . Setelah Anda menerima JSON serial di sisi server, gunakan fs.writeFileSync API untuk menulis laporan cakupan ke file (sekali lagi ada contoh lain di test.js yang menunjukkan bagaimana Anda dapat menulis file) .

@ Rob - W Saat ini saya tidak tersedia sampai tahun baru ... Saya akan mengetahuinya dengan pasti setelah itu

Setelah melakukan itu, Anda perlu mengubah test / test_slave.html menjadi tidak memuat tanpa syarat ../build/generic/build/pdf.js di

Setelah melakukan itu, Anda perlu mengubah test / test_slave.html menjadi tidak memuat tanpa syarat ../build/generic/build/pdf.js di

@ Rob - WI berhasil membuat parameter serupa di tests.js (dengan meniru parameter testFilter), namun, memasukkannya ke dalam test/test_slave.html masih menjadi masalah bagi saya. Untuk perubahan lainnya, silakan kunjungi PR lagi, saya telah memasukkan komitmen baru. # 9308

Juga jika Anda dapat memberi saya tautan untuk bergabung dengan saluran IRC atau milis slack / gitter / khusus untuk pdf.js.

@ Rob - A Apakah masalah masih berlanjut? Jika ya, saya ingin mengerjakannya.
Terima kasih.

Upaya pertama untuk ini ada di # 9308, jadi Anda bisa menggunakannya sebagai inspirasi. Mari fokus untuk membuat versi minimal berfungsi, yaitu versi yang hanya berfungsi secara lokal. Ini tidak harus bekerja pada bot atau Travis CI; jika kami dapat membuat laporan cakupan secara lokal, itu sudah sangat signifikan. Untuk lokal, akan lebih baik untuk membuat perintah bernama gulp coverage yang menjalankan pengujian unit berinstrumen dan menghasilkan laporan cakupan berdasarkan itu. Itu yang berfungsi dan digabungkan, kami selalu dapat mengulanginya.

@timvandermeij apakah masih aktif? Saya bisa mencobanya juga

Ya, silakan mengerjakan ini! Kita harus mulai dengan sederhana; lihat https://github.com/mozilla/pdf.js/issues/8632#issuecomment -455868037 untuk kemungkinan pendekatan.

@timvandermeij bertanya-tanya apakah saya bisa mencobanya? Satu pertanyaan besar yang saya miliki adalah apakah mungkin menggunakan skrip npm untuk menghasilkan laporan, atau jika itu harus menjadi tugas gulp ?

Saya tidak terlalu terbiasa dengan gulp tetapi saya bersedia belajar jika itu adalah persyaratan untuk ini

Saya tidak berpikir ada orang yang mengerjakan ini, jadi lanjutkan! Penting untuk membuatnya tetap sederhana untuk tambalan awal. Karena kami menggunakan Gulp sebagai perkakas utama kami, lebih disukai menggunakannya, tetapi kami juga terbuka untuk saran lain. Lihat https://github.com/mozilla/pdf.js/issues/8632#issuecomment -455868037 untuk ide implementasi. Ini tidak memerlukan banyak pengalaman dengan Gulp karena Gulp adalah pelari tugas yang cukup sederhana, yaitu, sebagian besar membungkus apa pun yang juga akan Anda lakukan dalam skrip NPM. Lihatlah Gulpfile untuk mendapatkan inspirasi.

Saya ingin mengerjakan ini. Apakah masalahnya masih terbuka? Dan di mana saya bisa lebih memahami bug?

@jezhou sedang mengerjakan ini dan telah membuat beberapa kemajuan dalam # 11580. PR belum baru-baru ini diperbarui.

Terima kasih banyak atas pembaruannya. Saya pikir saya bisa mulai mengerjakannya? Dimana
bisakah saya mendapatkan informasi lebih lanjut? Tentang masalah dan sisanya ??

Pada hari Sabtu, 16 Mei 2020, 17:56 Rob Wu, [email protected] menulis:

@jezhou https://github.com/jezhou sedang mengerjakan ini dan telah membuatnya
kemajuan dalam # 11580 https://github.com/mozilla/pdf.js/pull/11580 . PR
belum baru-baru ini diperbarui.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/mozilla/pdf.js/issues/8632#issuecomment-629637879 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AKUZ65CGSIZF6OMFZWENWF3RR2A77ANCNFSM4DSK7SGQ
.