[Kompilierung und Freigabe] Einige Test-Frameworks, die in Node.js verwendet werden können

NodeWelche Test-Frameworks können verwendet werden? Der folgende Artikel wird Ihnen einige Node.js-Testframeworks vorstellen. Ich hoffe, er wird Ihnen hilfreich sein!

Anmerkung des Herausgebers: Der Autor dieses Artikels ist Tianzhu, ein Ingenieur bei Ant Group Node.js. Am Ende des Artikels werden wir die häufig verwendeten Klassenbibliotheken vorstellen Besprechen Sie, ob Unit-Tests erforderlich sind. Gerne können Sie dies gemeinsam besprechen.

Häufig verwendete Klassenbibliotheken und Tools

Test Case Executor

Mocha und Jest werden häufiger verwendet. Der offizielle neue Knotentest wird noch ausgefeilt und die Zukunft ist vielversprechend.

$ mocha

  test/egg-view-ejs.test.js
    render
      ✓ should render with locals
      ✓ should render with cache
      ✓ should render with layout
      ✓ should render error
    renderString
      ✓ should renderString with data
      ✓ should renderString error

  6 passing (398ms)

Obwohl es so viele Runner gibt, liegen ihre Ausgabestandards alle im TAP-Format vor, und dann werden die Ergebnisse über verschiedene Reporter ausgegeben.

Abdeckungsstatistiken

Nur das Schreiben eines einzelnen Tests reicht nicht aus. Wir müssen wissen, ob alle Verzweigungsprozesse des Codes abgedeckt sind, daher müssen wir normalerweise Codeabdeckungstools verwenden.

Früher hieß es istanbuljs, und später hat der Autor es in nyc umgeschrieben. Sie tragen hauptsächlich zwei Aufgaben: Die eine besteht darin, den Code zum Einfügen des Stapelcodes zu übersetzen, und die andere besteht darin, verschiedene Reporter bei der Generierung von Berichterstattung zu unterstützen Berichte.

Später V8 integrierte Abdeckungsstatistiken

, was bedeutet, dass keine Übersetzung des Codes mehr erforderlich ist und die Erfassung von Abdeckungsdaten nativ unterstützt wird.

Dann schrieb dieser Autor c8, das sich auf die Erstellung von Berichterstattungsberichten konzentriert.

Assert-Klassenbibliothek

Um variable Ergebnisse zu überprüfen, ist Assert unerlässlich.

In der Geschichte gab es: expect.js, should.js, chai und power-assert, Jest hat auch einen eigenen Expect eingebaut.

Aber jetzt ist das offizielle assert/strict von Node.js tatsächlich ziemlich gut.

Unter diesen ist Power-Assert das, was wir bei EggJS die ganze Zeit verwendet haben. Ich habe es auch vor vielen Jahren verwendet: „Wahrscheinlich die beste JS Assert-Bibliothek – The Emperor's New Clothes“.

const assert = require('power-assert');

describe('test/showcase.test.js', () => {
  const arr = [ 1, 2, 3 ];

  it('power-assert', () => {
    assert(arr[1] === 10);
  });
});

// output:
4) test/showcase.test.js power-assert:

      AssertionError:   # test/showcase.test.js:6

  assert(arr[1] === 10)
         |  |   |
         |  2   false
         [1,2,3]

  [number] 10
  => 10
  [number] arr[1]
  => 2

PS: Wenn Sie den Dateiinhalt überprüfen möchten, habe ich auch eine assert-Datei geschrieben, die Sie gerne ausprobieren können.

Mock & Stub-Klassenbibliothek

Da es sich um einen Unit-Test handelt, ist es oft notwendig, die Umgebung oder nachgelagerte Antworten zu simulieren.

sinonjs Nicht schlecht, unterstützt Mocks, Stubs usw. Jest verfügt außerdem über eine eigene integrierte Mock-Bibliothek.

Wenn es sich um einen HTTP-Test handelt, ist nock sehr leistungsfähig und kann Ihnen dabei helfen, die Serverantwort zu simulieren.

nock('http://www.example.com')
  .post('/login', 'username=pgte&password=123456')
  .reply(200, { id: '123ABC' })

Allerdings verfügt die offizielle Node.js-Anfragebibliothek undici 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.

HTTP-Testbibliothek

Um HTTP-Server-Szenarien zu testen, ist die Supertest-Bibliothek unerlässlich.

describe('GET /users', function() {
  it('responds with json', async function() {
    return request(app)
      .get('/users')
      .set('Accept', 'application/json')
      .expect('Content-Type', /json/)
      .expect(200)
      .then(response => {
        assert(response.body.email, 'foo@bar.com');
      });
  });
});

Bibliothek für Befehlszeilentests

Eines der wichtigsten Verwendungsszenarien von Node.js ist die Befehlszeilen-CLI, wie Webpack, Babel usw., die selbst ebenfalls Unit-Tests benötigen.

Diese Empfehlung haben wir geschrieben:

• GitHub – node-modules/clet: Command Line E2E Testing

• GitHub – node-modules/coffee: Test command line on Node.js

  import { runner, KEYS } from 'clet';

  it('sollte mit Boilerplate funktionieren', async () => { warte auf Läufer() .cwd(tmpDir, { init: true }) .spawn('npm init') .stdin(/name:/, 'example') // auf stdout warten und 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 });

Tool zum automatischen Testen von Webseiten

Seiten leicht crawlen, Sie können die HTTP-Anforderungsbibliothek direkt verwenden, empfohlen undici.

Um die tatsächliche Ausführung des Browsers zu simulieren, waren es in den frühen Tagen Selenium und Phantomjs.

Dann veröffentlichte Google offiziell Puppenspieler. Aufgrund der Anhäufung von Chromium und basierend auf dem devtools-Protokoll-Protokoll wurde es schnell sehr beliebt und tötete die ersten beiden. Ähnliche Konkurrenzprodukte sind playwright und cypress.

Übrigens ist macacajs 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.

Kontinuierlicher Integrationsdienst

Wenn wir Open Source schreiben, benötigen wir häufig automatisierte kontinuierliche Integrationsdienste, die uns beim Testen helfen.

Zu den Spielern in diesem Bereich gehören: Travis, Appveyor, GitHub Actions usw.

Jetzt verwende ich grundsätzlich GitHub Actions, der Integrationsgrad ist so cool.

Diskutieren: Sind Unit-Tests notwendig?

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.

1. Ist das Schreiben von Unit-Tests Zeitverschwendung?

Lassen Sie mich zunächst den Standpunkt eines häufigen Neulings korrigieren: Unit-Tests zu schreiben ist 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 Regressionskosten berücksichtigen, nachdem der Code zweimal unter denselben Qualitätsanforderungen geändert wurde.

Für einen fairen Vergleich wird neben der Berücksichtigung der „Zeit zum Schreiben eines einzelnen Tests“ auch die „Zeit für Regressionstests nach jeder Codeänderung“ leicht übersehen:

• Wenn Sie einen einzelnen Test schreiben, erstellen Sie verschiedene Verzweigungsmocks in der frühen Phase, die Zeit für Regressionstests besteht nur darin, die Tastatur zu tippen
• 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 auf viele verschiedene Orte klicken.

Der Zeitaufwand dieser beiden ist auf einen Blick klar.

Es geht um nichts anderes als die Anfangsinvestition + die Wartungskosten + die Betonung der Renditequalität. Jedes Unternehmen hat seinen eigenen Maßstab, wenn es nach dem Abwägen der Gewichte Entscheidungen trifft.

Natürlich sind viele der von mir erwähnten Szenarien Framework-Bibliotheken (einschließlich Front-End und Node.js), serverseitige Anwendungen, Befehlszeilentools usw. Es stimmt, dass in einigen Front-End-Benutzeroberflächen der Schwerpunkt liegt Anwendungen oder schnelle Anwendungen, die sich stark geändert haben. Die entsprechenden Wartungskosten für einzelne Tests für die Up- und Down-Aktivitätsseiten sind in der Tat sehr hoch. Zu diesem Zeitpunkt ist es angemessen, 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 den Vergleich basierend auf Diff automatisieren und den Eigentümer dann daran erinnern soll, auf die Auswirkungen von Änderungen zu achten. Dies ist dasselbe wie die oben genannten Toolbibliotheken, die alle dazu dienen, die Kosten für das Schreiben einzelner Tests zu senken.

2. Sollten Unit-Tests nicht von Programmierern geschrieben werden?

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 gibt es keine qualitativ hochwertige Zusammenarbeit bei der Codeüberprüfung.

Teststudierende sind für umfangreichere Arbeiten wie Integrationstests, Regressionstests, End-to-End-Tests usw. verantwortlich

Die Arbeitsteilung ist anders, bitte geben Sie nicht anderen die Schuld.

also...

Das Schreiben von Unit-Tests ist die grundlegende professionelle Qualität von Programmierern. In einzelnen Szenarien können Sie Entscheidungen basierend auf dem ROI treffen.

Weitere Informationen zu Knoten finden Sie unter:

nodejs-Tutorial!

Das obige ist der detaillierte Inhalt von[Kompilierung und Freigabe] Einige Test-Frameworks, die in Node.js verwendet werden können. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!