Welche Test-Frameworks können für Node verwendet werden? Der folgende Artikel stellt Ihnen einige Node.js-Testframeworks vor. Ich hoffe, er wird Ihnen hilfreich sein! 
Node.js-Schnelleinführungskurs: Geben Sie ein, um zu lernen
Anmerkung des Herausgebers: Der Autor dieses Artikels ist Tianzhu, ein Node.js-Ingenieur bei Ant Group. Er wird in jedem Teil zunächst die häufig verwendeten Klassenbibliotheken vorstellen und erörtern, ob Unit-Tests erforderlich sind gemeinsam zu besprechen.
Mokka und Scherz werden häufig verwendet. Der offizielle neue Knotentest wird noch ausgefeilt und die Zukunft ist vielversprechend.
$Mokka test/egg-view-ejs.test.js machen ✓ sollte mit Einheimischen rendern ✓ sollte mit Cache rendern ✓ sollte mit Layout gerendert werden ✓ sollte einen Fehler darstellen renderString ✓ sollte String mit Daten rendern ✓ sollte einen RenderString-Fehler verursachen 6 Durchgänge (398 ms)
Obwohl es so viele Runner gibt, liegen ihre Ausgabestandards alle im TAP-Format vor und die Ergebnisse werden über verschiedene Reporter ausgegeben.
Es reicht nicht aus, nur einen einzigen Test zu schreiben. Wir müssen wissen, ob alle Verzweigungsprozesse des Codes abgedeckt sind, daher müssen wir normalerweise Code-Coverage-Tools verwenden.
Früher war es Istanbuljs, aber später hat der Autor NYC neu geschrieben. Sie tragen hauptsächlich zwei Aufgaben: Die eine besteht darin, den Code zu übersetzen, um den Stapelcode einzufügen, und die andere darin, verschiedene Reporter bei der Erstellung von Berichterstattungsberichten zu unterstützen.
Später integrierte V8-Abdeckungsstatistiken
Das bedeutet, dass der Code nicht mehr übersetzt werden muss und die Erfassung von Abdeckungsdaten nativ unterstützt wird.
Dann schrieb dieser Autor einen C8, der sich auf die Erstellung von Berichterstattungsberichten konzentrierte.
Um variable Ergebnisse zu überprüfen, ist Assert unerlässlich.
Historisch gesehen: Expect.js, Should.js, Chai und Power-Assert, Jest verfügt auch über einen eigenen integrierten Expect.
Aber jetzt ist Node.js offizielles Assert/Strict tatsächlich ziemlich gut.
Unter anderem haben wir bei EggJS Power-Assert verwendet. Ich habe es auch vor vielen Jahren erwähnt: „Wahrscheinlich die beste JS-Assert-Bibliothek – The Emperor's New Clothes“.
const behaupten = require('power-assert');
beschreiben('test/showcase.test.js', () => {
const arr = [1, 2, 3];
it('power-assert', () => {
behaupten(arr[1] === 10);
});
});
//Ausgabe:
4) test/showcase.test.js Power-Assert:
AssertionError: # test/showcase.test.js:6
behaupten(arr[1] === 10)
|. |
|. 2 falsch
[1,2,3]
[Anzahl] 10
=> 10
[Anzahl] arr[1]
=> 2PS: Wenn Sie den Dateiinhalt überprüfen möchten, habe ich auch eine Assertion-Datei geschrieben, die Sie gerne ausprobieren können.
Da es sich um einen Unit-Test handelt, ist es oft notwendig, die Umgebung oder nachgelagerte Antworten zu simulieren.
sinonjs ist nicht schlecht und unterstützt Mocks, Stubs usw. Jest verfügt außerdem über eine eigene integrierte Mock-Bibliothek.
Wenn es sich um HTTP-Tests handelt, ist Nock sehr leistungsfähig und kann Ihnen dabei helfen, die Serverantwort nachzuahmen.
nock('http://www.example.com')
.post('/login', 'username=pgte&password=123456')
.reply(200, { id: '123ABC' })Die offizielle Undici-Anfragebibliothek von Node.js verfügt jedoch auch über integrierte Mock-Funktionen.
Es gibt auch einen Begriff namens Snapshot, der bedeutet, dass die Daten während des Betriebs gespeichert und direkt als Scheindaten für den nächsten Test verwendet werden, was die Effizienz beim Schreiben von Tests bis zu einem gewissen Grad verbessern kann.
Um HTTP-Server-Szenarien zu testen, ist die Supertest-Bibliothek unverzichtbar.
beschreiben('GET /users', function() {
it('antwortet mit JSON', asynchrone Funktion() {
Rückgabeantrag (App)
.get('/users')
.set('Accept', 'application/json')
.expect('Content-Type', /json/)
.expect(200)
.then(response => {
behaupten(response.body.email, '[email protected]');
});
});
});Eines der wichtigsten Einsatzszenarien von Node.js ist die Befehlszeilen-CLI, wie z. B. Webpack und Babel, die selbst ebenfalls Unit-Tests erfordern.
Das empfehlen wir:
GitHub – node-modules/clet: Befehlszeilen-E2E-Tests
GitHub – node-modules/coffee: Testen Sie die Befehlszeile auf Node.js
import { runner, KEYS } from 'clet';
it('sollte mit Boilerplate funktionieren', async () => { waiting runner() .cwd(tmpDir, { init: true }) .spawn('npm init') .stdin(/name:/, 'example') // auf stdout warten, dann antworten .stdin(/version:/, new Array(9).fill(KEYS.ENTER)) .stdout(/"name": "example"/) // stdout validieren .notStderr(/ npm ERR/) .file('package.json', { name: 'example', version: '1.0.0' }) // Datei validieren });
Für ein leichtes Seiten-Crawling wird empfohlen, die Bibliothek direkt über HTTP anzufordern.
Um die tatsächliche Ausführung des Browsers zu simulieren, wurden in der Anfangszeit Selenium und PhantomJS verwendet.
Dann veröffentlichte Google offiziell Puppenspieler. Aufgrund der Anhäufung von Chromium und basierend auf dem Devtools-Protokoll wurde es schnell populär und tötete die ersten beiden. Ähnliche Konkurrenzprodukte sind Dramatiker und Zypresse.
Übrigens werde ich Macacajs herunterladen, ein Multi-Terminal-Testtool, das neben Browsern auch das Testen von mobilen APPs und Desktop-APPs unterstützt. Es ist Open Source und wird von Ingenieuren des Yuque-Teams bereitgestellt.
Wenn wir Open Source schreiben, benötigen wir häufig automatisierte kontinuierliche Integrationsdienste, die uns beim Testen helfen.
Zu den Akteuren in diesem Bereich gehören: Travis, Appveyor, GitHub Actions usw.
Jetzt verwende ich grundsätzlich GitHub Actions und der Grad der Integration ist so cool.
Es besteht kein Zweifel, dass Unit-Tests eine notwendige Fähigkeit und berufliche Qualität eines qualifizierten Programmierers sind.
Natürlich sind wir keine hundertprozentigen Abdeckungsfanatiker. In vielen Fällen müssen wir den Gleichgewichtspunkt des ROI verfolgen.
Lassen Sie mich zunächst den Standpunkt eines häufigen Neulings korrigieren: Ist das Schreiben von Unit-Tests Zeitverschwendung?
Tatsächlich sparen Sie durch das Schreiben von Unit-Tests Zeit. Der Grund für diese kontraintuitive Sichtweise ist, dass die Vergleichsbedingungen oft nicht objektiv sind. Wir müssen die Kosten der Regression berücksichtigen, nachdem wir den Code zweimal unter denselben Qualitätsanforderungen geändert haben.
Für einen fairen Vergleich wird neben der Berücksichtigung der „Zeit zum Schreiben eines einzelnen Tests“ leicht die „Zeit zum Durchführen eines Regressionstests nach jeder Codeänderung“ übersehen:
Wenn Sie einen einzelnen Test schreiben, erstellen Sie in der frühen Phase verschiedene Verzweigungsmodelle, und die Zeit für Regressionstests besteht nur aus dem Tippen auf der Tastatur.
Ohne einen einzigen Test zu schreiben, müssen Sie den Code in der Anwendung aktualisieren und dann verschiedene Situationen zum Testen manuell simulieren, z. B. das Öffnen eines Browsers und das Klicken auf viele verschiedene Stellen.
Wie zeitaufwändig diese beiden sind, wird auf den ersten Blick klar.
Es geht um nichts anderes als Anfangsinvestition + Wartungskosten + Wert auf Renditequalität. Jedes Unternehmen hat seinen eigenen Maßstab, wenn es Entscheidungen nach Abwägung trifft.
Natürlich handelt es sich bei vielen der von mir erwähnten Szenarien um Framework-Bibliotheken (einschließlich Front-End und Node.js), serverseitige Anwendungen, Befehlszeilentools usw. Es stimmt, dass bei einigen Front-End-Anwendungen große Änderungen vorgenommen wurden Die Anzeige der Benutzeroberfläche oder das schnelle Laden und Entladen sind für die Aktivitätsseite in der Tat sehr hoch. Zu diesem Zeitpunkt ist es sinnvoll, die einzelnen Tests einiger nicht zum Kerngeschäft gehörender Zweige auf der Grundlage des ROI aufzugeben.
Aber wir müssen verstehen, dass dies der letzte Ausweg ist. Wir können die Wartungskosten von Unit-Tests auf verschiedene Weise reduzieren, aber wir können nicht behaupten, dass Unit-Tests nutzlos sind.
Es gibt auch einen halbautomatischen Regressionstest im Front-End-Bereich, der auf Diff basiert, um den Vergleich zu automatisieren und den Eigentümer dann daran zu erinnern, auf die Auswirkungen von Änderungen zu achten. Dies ist genau wie die oben genannten Toolbibliotheken, die alle dazu dienen, die Kosten für das Schreiben einzelner Tests zu senken.
Dies ist auch eine falsche Ansicht. Unit-Tests sollten von Programmierern selbst geschrieben werden , da es sich um Ihren eigenen Code handelt und Sie dafür verantwortlich sein müssen. Jedes Team mit ein wenig Standardisierung muss beim Einreichen von Code CI-Tests durchführen, andernfalls wird es keine qualitativ hochwertige Zusammenarbeit bei der Codeüberprüfung geben.
Teststudenten sind für umfangreichere Arbeiten wie Integrationstests, Regressionstests und End-to-End-Tests verantwortlich .
Die Arbeitsteilung ist anders, also geben Sie bitte nicht anderen die Schuld.
Das Schreiben von Unit-Tests ist die grundlegende berufliche Eigenschaft eines Programmierers. In einzelnen Szenarien können Sie Entscheidungen basierend auf dem ROI treffen.