Pdf.js: Generieren Sie (Test-) Abdeckungsstatistiken

unittestcli - Führt einige Komponententests von PDF.js in Node.js aus (mit minimalen Quellenänderungen, nur mit Transpilation mit babel).
Browsertest - Führt Tests in Browsern aus (wir testen Chrome und Firefox). Dies basiert auf der Binärdatei, die vom Build-Ziel generic wurde und Code verwendet, der mit babel transpiliert und dann mit Webpack gebündelt wurde.

Beachten Sie, dass während browsertest die Referenz Tests ausgeführt wird, gibt es auch den unittest Befehl, der den vollständigen Satz von Unit - Tests in Browsern läuft (im Gegensatz zu unittestcli , die nur eine Teilmenge läuft der bestehenden Unit-Tests).

Beachten Sie außerdem, dass der Schritt "Transpilation mit Babel" übersprungen werden kann, wenn das Build-Flag PDFJS_NEXT gesetzt ist (entweder wie andere Build-Flags in gulpfile.js oder als Befehlszeilenargument). Während der Code noch mit Webpack gebündelt ist, ist es zumindest möglich, den Transpilationsschritt zu vermeiden.

@ Rob - WI würde gerne daran arbeiten

Es ist deins! Lassen Sie uns wissen (vorzugsweise im IRC), wenn Sie Fragen haben.

@timvandermeij Ich denke darüber nach, das Karma-Tool zu verwenden. Es funktioniert mit der Istanbul Code Coverage Engine. Statistiken können für die Testausführung überprüft werden. HTML-Berichte können daraus erstellt werden. Ist dies ein guter Anfang?

Mit Karma habe ich Testberichte https://drive.google.com/file/d/0ByddvU1PKkWaWEZTWHFYT0Y0aTg/view?usp=sharing erhalten
Statistiken zur Testabdeckung werden jedoch nicht angezeigt. https://drive.google.com/file/d/0ByddvU1PKkWaS1ZiT1dobU1DQUk/view?usp=sharing

@ Divya063 Könnten Sie Ihren Code teilen, z. B. indem Sie Ihren aktuellen Code in einen Zweig auf Ihrer pdf.js-Gabel auf Github verschieben? Ich frage mich, ob Webpack oder Babel bei Bedarf ausgeführt werden.

Und welche Version von Node.js verwenden Sie?

Vielen Dank für die Antwort, Node-Version ist 6.11.1. Hier ist der Link zum Zweig https://github.com/Divya063/pdf.js/tree/dev

Die Fehler sind:

Firefox 43.0.0
SyntaxError: Importdeklarationen werden möglicherweise nur auf oberster Ebene angezeigt
Chrome 60.0.3112
Nicht erfasster SyntaxError: Unerwarteter Token-Import

Dies zeigt an, dass der Code vor der Verwendung nicht transpiliert wird. Derzeit gibt es eine integrierte Unterstützung für ES-Module, die in keinem Browser standardmäßig aktiviert ist ( weitere Informationen ). Daher muss der Code zuerst transpiliert werden.

Ich habe meinen ersten Beitrag bearbeitet, um darauf hinzuweisen, wo die Transpilation im Build-System von PDF.js konfiguriert ist. Vielleicht können Sie versuchen, ein vorhandenes Plugin zu verwenden, um Istanbul und Babel zu integrieren. Eine Schnellsuche zeigt https://github.com/istanbuljs/babel-plugin-istanbul , aber es gibt möglicherweise auch andere Optionen.

(und die aktuelle stabile Version von Firefox ist 55. Sie haben mit Firefox 43 getestet, das uralt ist und nicht unterstützt wird. Ich schlage vor, dass Sie vor dem erneuten Testen auf eine neuere Version von Firefox aktualisieren.)

@ Rob - W Vielen Dank für die Angabe der Fehler. Ich werde bald mit den Ergebnissen aktualisieren.

@ Rob - WI hat den Code mit karma-browserify transpiliert und die Firefox-Version aktualisiert, aber es treten immer noch viele Fehler auf. Hier ist der Link zum Zweig https://github.com/Divya063/pdf.js/tree / dev

Können Sie die Fehlermeldungen teilen?

Und wenn möglich, versuchen Sie, Webpack anstelle von browserify zu verwenden, da Webpack bereits verwendet wird. Auf diese Weise können wir den Code instrumentieren, der tatsächlich im Browser verwendet wird.

Und ich sehe auch, dass Sie .idea und andere benutzerspezifische Projekt- / IDE-Dateien einchecken. Wenn Sie zu einem vorhandenen Projekt beitragen, ist es besser, dem Projekt keine nicht verwandten Dateien hinzuzufügen, da dies das Repository überfüllt und Zusammenführungskonflikte verursacht. In der endgültigen Pull-Anforderung sollten diese Dateien nicht enthalten sein.

Ist dieses Problem noch offen? Wenn ja, würde ich gerne daran arbeiten.

Ja, Sie können gerne daran arbeiten.

@ Timvandermeij
Ich habe daran gearbeitet. Ich habe Istanbul verwendet, um meine Tests abzudecken, und Overalls, um die Berichte anzuzeigen. Ich habe die erforderlichen Änderungen vorgenommen, wo immer dies erforderlich ist. Allerdings, wann immer ich Overalls mit benutze

npm run coveralls

Ich erhalte den folgenden Fehler

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

Ich habe versucht, dies hier und hier nachzuschlagen, aber ohne Erfolg. Hilfe bei dem Problem?

Es ist schwer zu sagen, ohne den Code zu sehen. Könnten Sie den Code an eine Zweigstelle weiterleiten, damit die Mitwirkenden hier mitschauen können?

@ Timvandermeij hier ist es. Bitte ignorieren Sie die Gem-Datei. Ich habe es bereits entfernt.

Irgendwelche Kommentare @timvandermeij

Nach einigem Googeln bedeutet dieser Fehler, dass coveralls keine Daten im Format lcov erhält. Sie können überprüfen, ob die einzelnen Befehle in npm run cover -- --report lcovonly && cat ./coverage/lcov.info | coveralls tatsächlich die erwarteten Ergebnisse zurückgeben.

@ Timvandermeij
Das Hauptproblem ist derzeit diese Aussage
No coverage information was collected, exit without writing coverage information
Aus diesem Grund bleibt die lcov-Datei jederzeit leer und dies geschieht

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

Beim Googeln scheinen dies sehr häufige Fehler zu sein. und der Fehler liegt im Grunde bei Istanbul. Ich habe versucht, zwischen verschiedenen Versionen derselben zu wechseln, aber der Fehler trat immer wieder auf. An allen Stellen wurden die Tests jedoch mit Mokka und nicht mit Flusen oder Unittest usw. durchgeführt, und daher sind die meisten (fast) Auflösungen auch nur für Mokka. Dies waren einige Quellen, nach denen ich gesucht habe

https://github.com/gotwarlost/istanbul/issues/262
https://github.com/coryhouse/react-slingshot/issues/245
https://github.com/gotwarlost/istanbul/issues/496
und einige andere auch, aber keiner von ihnen hat tatsächlich geholfen :(

Der Build wird auf Travis übergeben ( https://travis-ci.org/shikhar-scs/pdf.js/jobs/318422621 ), aber auch hier wird die Abdeckung nicht generiert.

Ich bin mir nicht sicher, warum das passiert, aber ich finde auch viele Leute, die es mit Jasmine erfolgreich gemacht haben, also muss es möglich sein. Könnten Sie versuchen, ob https://bryce.fisher-fleig.org/blog/setting-up-istanbul-with-jasmine/index.html für Sie funktioniert? Probieren Sie zuerst genau diese Schritte aus, um festzustellen, ob sie eigenständig funktionieren, und versuchen Sie dann, sie in PDF.js zu integrieren.

@ Timvandermeij drauf
Es werden nun endlich Berichterstattungsberichte erstellt. Ich muss jedoch transpilieren und dann testen, da Probleme mit den Import- und Exportanweisungen auftreten
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)
Dieser Fehler tritt bei jeder einzelnen js-Datei auf, und ich werde daran arbeiten und bald eine PR einreichen.

@ Timvandermeij

Hier sind sie: der Build geht vorbei und fordert Berichterstattung .

Die Berichterstattung berichtet

Da die Import- und Exportanweisungen jedoch auch nach Erreichen dieser Dateien vorhanden sind, werden sie nicht vollständig getestet, sodass wir Berichte zur Abdeckung von 0% erhalten. Soweit ich weiß, muss ich diese Dateien vor dem Jasmin-Test auf ES6 babelifizieren, und das erweist sich als Problem. Wie versorge ich Jasmin mit ES6-Code?
Kann ich Änderungen an der gulp-Datei vornehmen, wie hier erwähnt: http://jpsierens.com/use-es6-right-now/ ?

Sie nähern sich tatsächlich der Lösung. Aus den Abdeckungsberichten geht hervor, dass Sie die Abdeckung für die lib -Dateien ausführen, die bereits auf ES6 transpiliert werden sollten (siehe https://github.com/mozilla/pdf.js/blob/6ac9e1c5ed0d5f067872b8482724c171c79566b2/gulpfile). js # L965 und https://github.com/mozilla/pdf.js/blob/6ac9e1c5ed0d5f067872b8482724c171c79566b2/gulpfile.js#L985). Oder ist das Problem, dass die Unit-Tests selbst nicht transpiliert werden? Ich bin nicht wirklich damit vertraut, wie das genau funktioniert, aber wenn dies der Fall ist, sind möglicherweise einige Änderungen am Gulpfile für die Komponententests erforderlich.

@ Timvandermeij

Oder ist das Problem, dass die Unit-Tests selbst nicht transpiliert werden? Ich bin nicht wirklich damit vertraut, wie das genau funktioniert, aber wenn dies der Fall ist, sind möglicherweise einige Änderungen am Gulpfile für die Komponententests erforderlich.

Das Problem war, dass ich die Tests im falschen Ordner ausgeführt habe. build>lib Ordner
Ein weiteres Problem war die Anweisung --report lcovonly . Magischerweise (ich weiß wirklich nicht warum), als ich diesen Teil aus der Overalls-Linie entfernte, wurden Berichte generiert. Vielleicht hätte ich mehr Aufmerksamkeit schenken sollen

Sie können überprüfen, ob die einzelnen Befehle in npm cover - --report lcovonly && cat ./coverage/lcov.info | ausführen Overalls liefern tatsächlich die Ergebnisse, die Sie erwarten.

Vielen Dank für den Hinweis.

Endlich können wir Berichte erstellen: tada: und obwohl sie ein bisschen traurig aussehen, werden Sie beim Lesen der genauen Dateien den Grund dafür finden -

1. Alle nicht ausgeführten bedingten Anweisungen werden als "nicht abgedeckt" gezählt.
2. Alle nicht ausgeführten Zuweisungsanweisungen werden ebenfalls als "nicht abgedeckt" gezählt.

Ich habe die generierten Berichte offensichtlich nicht selbst hochgeladen, sondern sie über einen Link hier http://pdfjscoveragereport.bitballoon.com gehostet. Bitte besuchen Sie diese Links und Sie erhalten den genauen erwarteten Bericht.

Diese Ergebnisse spiegeln sich jedoch nicht in coveralls.io wider: cry: Ich weiß nicht warum. Außerdem ist mir aufgefallen, dass coveralls mein Projekt auch nach mehrmaligem

Trotzdem gibt npm run coveralls die gesamten Berichterstattungsberichte in diesem Format aus, die im Ordner build/lib/coverage/lcov-report .

Ich hoffe, all dies hilft endlich, aber unser letztes Problem ist es, diese Berichte irgendwie in Overalls zu zeigen.

Dies ist der Link für meinen neuesten Build. https://travis-ci.org/shikhar-scs/pdf.js
Dies ist der Link für mein letztes Commit .

Abgesehen von den Berichten, die nicht auf coveralls.io erstellt wurden, ist alles in Ordnung, denke ich. Soll ich also eine PR erstellen, da diese die Aufmerksamkeit vieler weiterer Personen auf sich zieht und dieses Problem möglicherweise früher löst?

Gute Arbeit! Es ist wirklich gut, eine Vorstellung von der Berichterstattung zu haben, und die Berichte geben uns das endlich. In der Tat zeigt es deutlich, dass wir viel mehr Unit-Tests benötigen, aber alle Methoden, für die wir kürzlich Unit-Tests hinzugefügt haben, werden tatsächlich wie im Bericht beschrieben angezeigt, sodass dies vollkommen in Ordnung aussieht.

Ich frage mich, ob es möglich wäre, die Abdeckung über die Quelldateien anstelle der erstellten Dateien auszuführen. Das macht es einfacher zu verstehen, denn jetzt unter http://pdfjscoveragereport.bitballoon.com/lib/display/metadata.js.html sehe ich, dass Zeile 28 nicht behandelt wird, obwohl dies nicht unser Code ist, sondern automatisch generierter Code. Wenn es sich als schwierig herausstellt, können wir den aktuellen Ansatz einfach als erste Version ausführen und dies in einem Folgeproblem tun.

Soll ich also eine PR erstellen, da diese die Aufmerksamkeit vieler weiterer Personen auf sich zieht und dieses Problem möglicherweise früher löst?

Ja, das ist eine gute Idee. Wir können dann den Überprüfungsprozess starten und sehen, welche Probleme noch zu lösen sind.

Es ist wirklich gut, eine Vorstellung von der Berichterstattung zu haben, und die Berichte geben uns das endlich. In der Tat zeigt es deutlich, dass wir viel mehr Unit-Tests benötigen, aber alle Methoden, für die wir kürzlich Unit-Tests hinzugefügt haben, werden tatsächlich wie im Bericht beschrieben angezeigt, sodass dies vollkommen in Ordnung aussieht.

Zwar ist es sicher richtig, dass wir mit viel mehr Unit-Tests fertig werden könnten, aber es gibt große Teile der Codebasis, die wahrscheinlich nicht annähernd "gut" genug Testabdeckung erreichen werden, nur durch Unit-Tests allein leider.

Wie unter https://github.com/mozilla/pdf.js/issues/8632#issue -241690851 erwähnt, gibt es einige verschiedene Testsuiten, und wenn ich mich nicht irre, erhalte ich auch Abdeckungsergebnisse von gulp browsertest Es wäre fast unerlässlich, wirklich zu wissen, wie unsere tatsächliche Testabdeckung aussieht.

@ Snuffleupagus @ Timvandermeij

Heute Morgen habe ich ausgiebig versucht, Berichterstattungsberichte in allen Ordnern einzeln mit der Anweisung cd build && cd lib && istanbul cover --include-all-sources jasmine-node test , verschiedene Verzeichnisse mit cd <directory name> ändern und mit jasmine-node <directory names and js files> testen, aber vergebens.

Obwohl Testberichte manchmal (nicht immer) generiert werden, geschieht dies aufgrund der ein oder zwei js-Dateien im ES6-Format, die in den spezifischen Verzeichnissen liegen (was nur <2 ~ 3% der Abdeckungsberichte bringt). Leider gibt jede js-Datei, die import or export statements , einen Fehler in diesem Format zurück.

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

Und mit diesem Fehler wird die Datei überhaupt nicht auf Abdeckung überprüft und gibt daher einen 0% -Report zurück.

Ich frage mich, ob es möglich wäre, die Abdeckung über die Quelldateien anstelle der erstellten Dateien auszuführen.

Auch hier enthält der Quellordner Dateien mit Import- und Exportanweisungen. Daher treten die oben genannten Fehler auf, aufgrund derer die zugehörigen Dateien überhaupt nicht überprüft werden, was zu einer Abdeckung von 0% führt.

Daher ist es unbedingt erforderlich, dass wir im Build-Ordner selbst testen.

Um auch wirklich zu wissen, wie unsere tatsächliche Testabdeckung aussieht, ist es fast unerlässlich, die Ergebnisse der Berichterstattung auch vom Schluck-Browsertest zu erhalten.

@ Snuffleupagus Wo liegen diese spezifischen Tests? Wir können versuchen, sie direkt mit der oben erwähnten Jasmin-Knoten-Anweisung zu testen.

Wenn es sich als schwierig herausstellt, können wir den aktuellen Ansatz einfach als erste Version ausführen und dies in einem Folgeproblem tun.

Ja, das könnten wir lieber tun.

Ja, das ist eine gute Idee. Wir können dann den Überprüfungsprozess starten und sehen, welche Probleme noch zu lösen sind.

Klar, ich fange damit an.

Die PR unter # 9308 hat ein Beispiel für die Testabdeckung nur für die Komponententests gezeigt. Die generierten Berichte bieten wenig Wert, da unsere Unit-Tests sehr klein sind. Weitere Informationen finden Sie unter https://github.com/mozilla/pdf.js/pull/9308#issuecomment -353588039

Um Browsertests zu erhalten, benötigen wir also:

1. Eine Möglichkeit, Abdeckungsdaten zu generieren.
2. Eine Möglichkeit, die Abdeckungsdaten abzurufen (und in Overalls hochzuladen).

Um Adresse 1) zu adressieren, sollte gulpfile.js bearbeitet werden, um optional Code-Instrumente hinzuzufügen, die in einem Browser in das Objekt window.__coverage__ exportiert werden. gulp-istanbul könnte nützlich sein. Die Dokumentation scheint spärlich zu sein, aber ich habe ein Beispiel unter https://stackoverflow.com/questions/38208735/no-window-coverage-object-is-created-by-istanbul-phantomjs gefunden. Wir verwenden NICHT PhantomJS, aber Sie können die Frage, Antwort und den verknüpften Blog-Beitrag lesen, um Ihr Verständnis für die Funktionsweise zu vertiefen.

Nach Abschluss von Schritt 1 haben die Browsertests eine Variable window.__coverage__ (oder was auch immer Sie in den Konfigurationsparameter coverageVariable eingegeben haben). So erhalten Sie Berichterstattungsberichte:

1. Ändern Sie den Testläufer (https://github.com/mozilla/pdf.js/blob/e081a708c36cb2aacff7889048863723fcf23671/test/driver.js), um das Abdeckungsergebnis mit XMLHttpRequest auf dem Testserver zu veröffentlichen.
2. Registrieren Sie auf dem Testserver (https://github.com/mozilla/pdf.js/blob/e081a708c36cb2aacff7889048863723fcf23671/test/test.js) einen neuen Hook, um Testergebnisse zu erhalten, und schreiben Sie diesen mit fs in eine Datei
3. Laden Sie den Bericht in Overalls hoch (z. B. mit dem Befehl "Overalls", wie in # 9308 gezeigt).

@ Rob - W Danke für die ausführliche Bewertung. Ich werde nachgehen und so schnell wie möglich zurückkehren.

Dieser Kommentar bietet Tipps für die Implementierung und behandelt die Fragen unter https://github.com/mozilla/pdf.js/pull/9308#issuecomment -353710595

istanbul fügt dem Code nur Instrumente hinzu. Diese Eingabe soll ausführbarer Code sein, da "Instrumentierung" das Hinzufügen von zusätzlichem JavaScript-Code bedeutet, der erkennt, wann die Ausführung diese Zeile, Anweisung usw. durchläuft. Wenn der Code nach dem Hinzufügen der Instrumentierung erneut erheblich geändert wird, wird der resultierende Abdeckungsbericht bedeutungslos.

Diese Instrumentierung kann im laufenden Betrieb durchgeführt werden, während das Programm ausgeführt wird (z. B. wenn Sie istanbul cover über die Befehlszeile ausführen, fängt istanbul Aufrufe von Node.js require und transformieren Sie den Code mit Instrumentierung, bevor das Modul geladen wird ) oder getrennt von der Ausführung (z. B. wie der Blog-Beitrag zeigt: Der instrumentierte Code wird in der Befehlszeile generiert, die Ausführung erfolgt im Browser).

In Ihrer aktuellen PR unter # 9308 rufen Sie istanbul cover mit jasmine als Programm auf. Wie ich bereits erwähnt habe, ähnelt der Effekt dem Ausführen von gulp unittestcli - dh die Tests werden für eine vorgefertigte Bibliothek im Verzeichnis build/lib (dies ist in test/unit/clitests.json konfiguriert). . Dies erklärt, warum Ihr Abdeckungsbericht 0 Abdeckungen für alles außer build/lib/ (da die einzigen require -d (Node.js) -Module in build/lib und build/streams/ - siehe Ende der gulp unittestcli Aufgabendefinition ).

Um nützliche Abdeckungsberichte zu erhalten, befinden sich die Abdeckungsberichte vorzugsweise auf Modulebene. Dies ist ein Schritt voraus: Sie müssen istanbul in die Build-Pipeline integrieren, damit beim Transpilieren des Codes aus ES6 die Instrumentierung hinzugefügt wird. Danach wird es schwieriger, Berichte pro Modul zu erstellen (aber nicht unmöglich, theoretisch liefern Quellkarten genügend Informationen, um Daten den Originaldateien zuzuordnen).
Dies ist eine Herausforderung und erfordert ein gutes Verständnis der Verwendung von Babel, gulp, istanbul und Quellkarten / -modulen (ich habe bereits auf die relevanten Stellen im Quellcode verwiesen, an denen PDF.js alle Module zusammenführt, um die PDF.js zu generieren Bibliothek - siehe # 8632). Dieses Wissen ist sehr nützlich. Wenn Sie also keine Angst vor Herausforderungen haben, können Sie dies unter meiner Anleitung untersuchen.

Bevor wir jedoch so tief eintauchen, beginnen wir mit etwas Einfacherem: Abrufen von Berichterstattungsberichten über den Browser. Wir haben zwei Möglichkeiten, Tests im Browser auszuführen: unittest und browsertest . Da wir in Node.js bereits eine recht einfache Möglichkeit zum Ausführen von Komponententests haben, konzentrieren wir uns auf browsertest . Die Browsertests verwenden keine einzelnen Module, sondern die PDF.js-Bibliothek, die vom generic gulp-Ziel in GENERIC_DIR , auch bekannt als build/generic/ . Es reicht also aus, build/generic Code-Instrumentierung hinzuzufügen. Ich schlage vor, build/generic/ als Eingabeverzeichnis zu verwenden und das Ergebnis in coverage/build/generic schreiben.

Danach tut, müssen Sie ändern test/test_slave.html nicht bedingungslos laden ../build/generic/build/pdf.js in <script> - Tag, aber bedingt entweder laden ../build/generic/build/pdf.js oder ../coverage/build/generic/build/pdf.js abhängig von einigen Konfigurationsparametern (zum Testen können Sie nur die letztere URL fest codieren. Es ist sehr einfach, diesen fest codierten Parameter später zu ändern, nachdem Sie die schwierigere Aufgabe des Zurücksendens des Abdeckungsberichts an den Testserver abgeschlossen haben.) .

Sobald Sie die normale pdf.js -Bibliothek durch die instrumentierte pdf.js-Bibliothek ersetzt haben, wird die Abdeckungsstatistik als Testlauf generiert. Das Ergebnis wird in der globalen Variablen window.__coverage__ gespeichert. Wenn der Testtreiber im Browser beendet ist ( JSON.stringify(window.__coverage__) ) und ihn mit XMLHttpRequest an den Server senden driver.js . Stellen Sie sicher, dass Sie den Bericht an den Server senden, bevor Sie die Nachricht /tellMeToQuit senden. Andernfalls wird der Bericht möglicherweise nicht übertragen korrekt).
Sie können einen neuen Handler für Ihren neuen benutzerdefinierten API-Aufruf unter https://github.com/mozilla/pdf.js/blob/ba5dbc96326518ad716158ef040f61794cc72202/test/test.js hinzufügen. Schauen Sie sich für Codebeispiele XMLHttpRequest Aufrufe in driver.js (z. B. die Nachricht /tellMeToQuit ) und suchen Sie den entsprechenden Handler in test.js . Wenn Sie den serialisierten JSON auf der Serverseite erhalten haben, verwenden Sie die API fs.writeFileSync , um den Abdeckungsbericht in eine Datei zu schreiben (es gibt wieder andere Beispiele in test.js , die zeigen, wie Sie Dateien schreiben können). .

@ Rob - W Ich bin momentan erst im neuen Jahr verfügbar ... danach werde ich es sicher verstehen

Danach müssen Sie test / test_slave.html so ändern, dass es nicht unbedingt ../build/generic/build/pdf.js in a lädt

Danach müssen Sie test / test_slave.html so ändern, dass es nicht unbedingt ../build/generic/build/pdf.js in a lädt

@ Rob - WI hat es geschafft, einen ähnlichen Parameter im tests.js zu erstellen (durch Nachahmung des testFilter-Parameters), aber die Aufnahme in den test/test_slave.html ist für mich immer noch ein Problem. Für den Rest der Änderungen besuchen Sie bitte die PR erneut, ich habe neue Commits gepusht. # 9308

Auch wenn Sie mir Links für den Beitritt zum IRC-Kanal oder zur Slack / Gitter / Mailing-Liste für pdf.js zur Verfügung stellen könnten.

@ Rob - W Ist das Problem noch offen? Wenn ja, würde ich gerne daran arbeiten.
Vielen Dank.

Der erste Versuch hierfür ist in # 9308, sodass Sie dies als Inspiration verwenden können. Konzentrieren wir uns darauf, eine minimale Version zum Laufen zu bringen, dh eine, die nur lokal funktioniert. Es muss nicht auf den Bots oder Travis CI funktionieren; Wenn wir lokal Bericht erstatten können, ist das bereits sehr wichtig. Für lokal wäre es gut, einen Befehl namens gulp coverage erstellen, der instrumentierte Komponententests ausführt und darauf basierend einen Abdeckungsbericht generiert. Wenn es funktioniert und zusammengeführt wird, können wir es immer wiederholen.

@ Timvandermeij ist es noch aktiv? Ich kann es auch versuchen

Ja, zögern Sie nicht, daran zu arbeiten! Wir sollten einfach anfangen; Einen möglichen Ansatz finden Sie unter https://github.com/mozilla/pdf.js/issues/8632#issuecomment -455868037.

@ Timvandermeij fragen sich, ob ich dies gulp -Aufgabe handeln muss.

Ich bin mit gulp nicht allzu vertraut, aber ich bin bereit zu erfahren, ob dies eine Voraussetzung dafür ist

Ich glaube nicht, dass irgendjemand daran arbeitet, also mach weiter! Es ist wichtig, es für den ersten Patch einfach zu halten. Da wir Gulp als Hauptwerkzeug verwenden, wird es bevorzugt, dies zu verwenden, aber wir sind auch offen für andere Vorschläge. Implementierungsideen finden Sie unter https://github.com/mozilla/pdf.js/issues/8632#issuecomment -455868037. Es erfordert jedoch nicht viel Erfahrung mit Gulp, da Gulp ein ziemlich einfacher Task-Runner ist, dh meistens alles einschließt, was Sie auch in einem NPM-Skript tun würden. Schauen Sie sich das Gulpfile an, um sich inspirieren zu lassen.

Daran möchte ich arbeiten. Ist das Problem noch offen? Und wo kann ich den Fehler besser verstehen?

@jezhou hat daran gearbeitet und in # 11580 einige Fortschritte gemacht. Die PR wurde jedoch kürzlich nicht aktualisiert.

Vielen Dank für das Update. Ich denke, ich kann anfangen daran zu arbeiten? Wo
kann ich weitere Informationen erhalten? Über das Problem und den Rest davon?

Am Samstag, 16. Mai 2020, 17:56 Uhr schrieb Rob Wu, [email protected] :

@jezhou https://github.com/jezhou hat daran gearbeitet und einige gemacht
Fortschritte in # 11580 https://github.com/mozilla/pdf.js/pull/11580 . Die Öffentlichkeitsarbeit
wurde jedoch kürzlich nicht aktualisiert.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/mozilla/pdf.js/issues/8632#issuecomment-629637879 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AKUZ65CGSIZF6OMFZWENWF3RR2A77ANCNFSM4DSK7SGQ
.