Sie befinden sich wahrscheinlich in einer von zwei Situationen. Entweder Ihr JavaScript-Projekt hat fast keine Tests und jede Refaktorisierung fühlt sich riskant an, oder Sie haben bereits Tests und die Hälfte davon ist langsam, brüchig und schwer zu vertrauen.
Das wird sich in Capacitor und Elektron-Anwendungen verschlimmern. Ein einfacher Feature kann gemeinsame Geschäftslogik, Browser-APIs, native Plugins, lokale Dateien, IPC und Remote-Dienste in derselben Fluss berühren. Wenn Sie diese Teile falsch testen, wird Ihr Suite ein Labyrinth von fiktiven Abhängigkeiten. Wenn Sie sie richtig testen, erhalten Sie schnelles Feedback auf die Logik, die bricht. You’re probably in one of two situations right now. Either your JavaScript project has almost no tests and every refactor feels risky, or you already have tests and half of them are slow, brittle, and oddly hard to trust.
Gute Einheitstests funktionieren JavaScript nicht mit cleverer Matcher-Syntax. Es beginnt mit einer disziplinierten Grenze: Testen Sie die reine Logik direkt, isolieren Sie die Nebeneffekte und vermeiden Sie es, Tests zu schreiben, die sich zusammenfallen, wenn Sie eine interne Funktion umbenennen.
Inhaltsverzeichnis
- Wählen Sie Ihren JavaScript-Testframework
- Projektsetup und Ihre erste Test
- Mocking und asynchrone Code meistern
- Fortgeschrittene Strategien für Robuste Tests
- Für CI, Capacitor, und Electron Apps testen
- Häufig gestellte Fragen zum JavaScript-Einheitstesten
Wählen Sie Ihren JavaScript-Testframework
Ein professionelles JavaScript-Projekt benötigt einen echten Testrunner. Ad-hoc-Skripte und manuelle Konsolenprüfungen schalen nicht, sobald mehrere Ingenieure an demselben Codebase arbeiten. Sie benötigen Testentdeckung, Anforderungen, asynche Handhabung, Mocks und eine Möglichkeit, alles konsistent in der lokalen Entwicklung und CI auszuführen.
Die aktuelle Leitlinie konvergiert immer wieder auf eine kleine Anzahl von Mainstream-Optionen. Jest, Mocha und Jasmine werden wiederholt als Hauptframeworks hervorgehoben, mit Jest oft für die integrierte Teststruktur, Anforderungen, Mocks und asynche Unterstützung in einem Paket hervorgehoben, wie in diesem Pluralsight-JavaScript-Testlab.
Warum ein Framework nicht optional ist
Auf die erste Fehlhandlung der Teams kommt es an, wenn sie Einheitstests als Nebenaktivität behandeln. Das führt normalerweise zu inkonsistenten Dateinamen, eigenen Behauptungen, die niemand mehr kennt, und Helfern, die nur einer Person versteht.
Eine Framework gibt Ihnen eine gemeinsame Sprache:
- Teststruktur mit
describeundtestoderit - Aussagen mit lesbaren Vergleichern
- Hooks zur Einrichtung und Demontage
- Asynchrone Unterstützung zur Verwendung von Versprechen und Zeitern
- Mocking-Werkzeuge für externe Abhängigkeiten
Wenn Ihr Team auch einen umfassenderen Überblick über die Testautomatisierung benötigt, der über die Einheitstestarbeit hinausgeht, hat Capgo einen nützlichen Überblick über automatisierte Tests in Anwendungslieferungsworkflows.
Jest vs Mocha im Überblick
Jest und Mocha vertreten zwei unterschiedliche Philosophien.
Jest ist die alles-in-einem-Lösung. Sie liefert mit der meisten, was Teams am ersten Tag benötigen.
Mocha ist modularer. Sie liefert einen Runner und erwartet, dass Sie den Rest der Stacks zusammenbauen.
| Feature | Jest | Mocha |
|---|---|---|
| Setup-Komplexität | Geringer für die meisten Teams | Höher, da du normalerweise Assertion- und Mocking-Bibliotheken hinzufügst |
| Anforderungen | Integriert | Normalerweise mit einer anderen Bibliothek kombiniert |
| Mocking | Integriert | Normalerweise mit einer anderen Bibliothek kombiniert |
| Asynchrone Tests | Integriert und unkompliziert | Unterstützt, aber hängt mehr von der Umgebung ab |
| Abdeckungsworkflow | Wird häufig in die gleiche Werkzeugkette integriert | Wird oft mehr zusammengefügt |
| Beste Wahl | Neue Projekte, Teams, die konsistente Ergebnisse wollen | Legacy-Stacks, Teams, die modularen Kontrolle wollen |
Praktische Regel: Wenn Ihr Team fragen muss, welche Assertion-Bibliothek und Mocking-Bibliothek mit dem Runner kombiniert werden sollen, wollen Sie wahrscheinlich Jest.
Was ich für die meisten Teams empfehle
Für die meisten modernen Projekte würde ich wählen Jest es sei das Codebase bereits starke Gründe hat, auf Mocha zu bleiben. Diese Empfehlung wird stärker, wenn die Anwendung Capacitor oder Electron, weil diese Projekte bereits genug bewegliche Teile haben. Die Reduzierung des Testwerkzeugspralls zahlt sich schnell aus.
Mocha macht noch immer Sinn in älteren Node.js-Diensten oder langlebigen Codebases, wo die Umgebung um es bereits abgesetzt ist. Aber für einen mittelständischen Ingenieur, der von vorneherein eine robuste Suite aufbaut, entfernt Jest normalerweise mehr Reibung als es schafft.
Ein wichtiger Umfangsvermerk. Cypress und Playwright sind ausgezeichnete Werkzeuge, aber sie lösen ein anderes Problem. Sie sind besser für Browser-Ebene- und End-to-End-Überprüfungen, nicht für die schnelle innere Schleife, wo Einheitstests JavaScript-Code leben sollten.
Projektsetup und Ihre erste Test
Ein sauberes Testsetup sollte langweilig sein. Wenn die Hinzufügung des ersten Tests kompliziert ist, wird die Suite wahrscheinlich nicht gesund bleiben.
Ein einfacher Jest-Setup
Beginnen Sie mit einem JavaScript-Projekt, das bereits eine package.json. Dann fügen Sie Jest als Entwicklungsabhängigkeit hinzu und verbinden Sie ein Testskript.
{
"scripts": {
"test": "jest"
}
}Das reicht für viele Projekte. Sie können später weitere Konfiguration hinzufügen, wenn Ihr Modulsystem, die Transpilation oder Ihre monorepositorische Struktur dies erfordern.
Wenn Sie ein Capacitor-Anwendungsprojekt lokal erstellen und Ihr Entwicklungsumfeld vor der Hinzufügung von Tests um die gemeinsame Logik in Ordnung bringen möchten, ist Capgo's Anleitung zum Einrichten eines Capacitor-lokalen Umfelds ein praktischer Begleiter.
Schreiben Sie den Test vor dem code.
Die Test-Vor-Vorlage ist nicht nur eine persönliche Vorliebe. Die U.S. Consumer Financial Protection Bureau's JavaScript-Richtlinie empfiehlt ausdrücklich den Test zu schreiben, bevor Sie die Implementierungorganisieren Sie Tests mit describe und itund definieren Sie Prüfungen um expect(...) Ansprüche in ihrem JavaScript-Einheitstestleitfaden.
Das ist wichtig, weil test-first die Art und Weise ändert, wie Sie code. Funktionen gestalten. Funktionen tendieren dazu, kleiner zu werden, Abhängigkeiten werden sichtbarer und Nebeneffekte stoppen, sie zu logik zu leiten, die rein bleiben soll.
Hier ist ein minimaler Beispiel:
// math.js
function addTax(amount, rate) {
return amount + amount * rate;
}
module.exports = { addTax };// math.test.js
const { addTax } = require('./math');
describe('addTax', () => {
it('returns the amount with the tax applied', () => {
expect(addTax(100, 0.2)).toBe(120);
});
});Verwenden Sie Arrange Act Assert immer
Der Arrange, Act, Assert Muster hält Tests lesbar, selbst wenn sie komplexer werden.
- Arrange die Eingabe und jede notwendige Vorbereitung.
- Act indem Sie die Funktion aufrufen.
- Assert On das Ergebnis.
Angewendet auf eine Validierungs-Hilfe:
function isSupportedPlatform(platform) {
return ['ios', 'android', 'web', 'desktop'].includes(platform);
}
describe('isSupportedPlatform', () => {
it('returns true for ios', () => {
// Arrange
const platform = 'ios';
// Act
const result = isSupportedPlatform(platform);
// Assert
expect(result).toBe(true);
});
});Kleine Tests halten gut. Ein Test sollte normalerweise eine Frage beantworten, nicht eine gesamte Workflow-erzählung.
Für Capacitor- und Electron-Projekte ist diese Disziplin wichtiger, weil Ihre logische Logik oft neben native oder Desktop-Integrationen sitzt code. Halten Sie die Geschäftsregel ohne die Plattform- Runtime testbar, und Ihr erster Test wird nicht Ihr letzter nützlicher sein.
Meisterung von Mocks und asynchronen Code
Die meisten Fehler in Anwendungen code kommen nicht von der Addition zweier Zahlen. Sie kommen von code die sich außerhalb selbst befindet: Netzwerk-Anfragen, Dateien, Plugin-APIs, Timer, IPC-Kanäle, Speicherschichten.
Dort hilft Mocking. Es gibt Ihnen die Kontrolle über die Grenze, damit der Test sich auf die Entscheidungsfindung Ihres code konzentrieren kann.
Mocken Sie Grenzen, nicht alles
Leitfaden für warten Tests betont Einzelverhaltensdeckung und Eine starke Behauptung pro Testund warnt auch davor, dass das übermäßige Verwenden von Mocks die Tests brüchig und eng an die Implementierung gekoppelt macht, wie in diesem Artikel von TestRail zu wartbaren Einheitstests.
Dieses Warnsignal ist in JavaScript sehr wichtig. Viele Teams beginnen damit, jeden importierten Modul zu mocken und enden damit, ob Funktionen andere Funktionen in der richtigen Reihenfolge aufrufen, anstatt das echte Verhalten zu testen.
Falsches Ziel für einen Test, der stark auf Mocks setzt:
- ob Hilfsfunktion A Helper B aufgerufen hat
- ob Dienst C Serializer D aufgerufen hat
- ob eine interne private Funktion zweimal aufgerufen wurde
Besseres Ziel:
- was die Funktion zurückgibt
- ob sie einen fehlgeschlagenen Abhängigkeit richtig behandelt hat
- ob sie die Daten in die erwartete Form transformiert hat
A bessere Muster für Capacitor und Electron code
Bei mobilen und Desktop-Anwendungen bevorzuge ich eine Wrapper-Schicht um native oder Plattform-APIs. Dann mockt die Einheitstests die Wrapper, nicht die Plattform selbst.
Beispielstruktur:
// cameraGateway.js
async function getPhoto(cameraPlugin) {
return cameraPlugin.getPhoto();
}
module.exports = { getPhoto };// profilePhotoService.js
async function loadProfilePhoto(cameraGateway) {
const photo = await cameraGateway.getPhoto();
return { path: photo.path, ready: true };
}
module.exports = { loadProfilePhoto };// profilePhotoService.test.js
const { loadProfilePhoto } = require('./profilePhotoService');
test('returns mapped photo data', async () => {
const fakeCameraGateway = {
getPhoto: jest.fn().mockResolvedValue({ path: '/tmp/pic.jpg' })
};
const result = await loadProfilePhoto(fakeCameraGateway);
expect(result).toEqual({ path: '/tmp/pic.jpg', ready: true });
});Dieses Muster funktioniert auch für Electron. Wrap ipcRendererDateizugriff, oder Shell-Integrationen hinter einer dünnen Adapter. Einheitstests treffen die Dienstschicht, nicht die Runtime direkt.
Für Teams, die die Release-Logik und Update-Pfade in Capacitor-Anwendungen testen, hat Capgo eine relevante Anleitung zu dem Testen von Capacitor OTA-Updates mit Mock-Szenarien.
Eine schnelle Durchführung hilft, wenn Ihr Team noch normalisiert den asynchronen Teststil:
Testen asynchroner Flüsse ohne Flakiness
Verwende async/await in Tests, wenn der code unter Test eine Promise zurückgibt. Es ist klarer als Muster mit callback-geprägten und einfacher zu debuggen.
async function fetchProfile(api) {
const response = await api.getUser();
return response.name;
}
test('returns the user name from the API response', async () => {
const api = {
getUser: jest.fn().mockResolvedValue({ name: 'Ava' })
};
const result = await fetchProfile(api);
expect(result).toBe('Ava');
});Teste auch den Fehlerpfad:
test('throws when the API request fails', async () => {
const api = {
getUser: jest.fn().mockRejectedValue(new Error('network failed'))
};
await expect(fetchProfile(api)).rejects.toThrow('network failed');
});Testen Sie sowohl den glücklichen als auch den unglücklichen Weg. In der Produktion ist der unglückliche Weg meist der, den die Benutzer merken.
Fortgeschrittene Strategien für robuste Tests
Ein Test-Suite wird nützlich, wenn sie nach den code Änderungen noch nützlich bleibt. Das ist schwieriger als das Schreiben einer Menge von erfolgreichen Tests.
Verwenden Sie den Test-Split als Budget
Ein praktischer Leitfaden empfiehlt eine 70/20/10 Zuweisung über Einheiten-, Integrations- und End-to-End-Tests, wobei Einheitstests die schnellste Rückmeldung und die stabilsten Fehler liefern. Die gleiche Leitlinie sagt, dass eine vollständige Einheitssuite idealerweise in unter 10 Sekundenabschließen sollte und die Prüfungen vor dem Commit sollten bleiben unter 5 Sekundennach diesem Anleitung zur OpenReplay-Testung.
Für mich ist das ein Budgetwerkzeug, kein Dogma. Wenn sich die meisten Anstrengungen auf End-to-End-Tests konzentrieren, wird das Team zu lange auf Feedback warten. Wenn alles nur Einzeltests sind, verpassen Sie die echten Systemgrenzen.
Für eine Capacitor- oder Electron-Anwendung sieht ein gesunder Ausgleich normalerweise so aus:
- Einzeltests für die Preisanpassung, Berechtigungsregeln, Serialisierung, Aktualisierungsbedingungen, Feature-Flags und Zustandsänderungen
- Integrations-Tests für Speicherverbindungen, Plugin-Wrapper und IPC-Verträge
- E2E-Tests für einige kritische Reiserouten wie Anmeldung, Kaufablauf, Synchronisierung oder Aktualisierungsanfragen
Deckungsgrad ist ein Taschenlampenlicht, kein Ziel
Deckungsgradsberichte sind nützlich, wenn sie Ihnen helfen, ungetestete Zweige in wichtigen Logik zu erkennen. Sie werden schädlich, wenn Teams Deckungsgradprozente für ihren eigenen Willen verfolgen.
A Login-Validator mit sorgfältig geprüften Randfällen liefert mehr Wert als ein vollständig dokumentierter Dateiinhalt mit trivialen Aussagen. Das gilt besonders für code mit hohem Eingabedruck wie Formulare, Parser, Datumlogik und Berechtigungsprüfungen. Wenn Ihr Team die Qualität um die Validierung schwerpunktierte UI herum schärft, ist diese Anleitung zum "Mastering von Frontend-Formvalidierung" eine gute Ergänzung zur Einheitsteststrategie. Mastering der Frontend-Formvalidierung ist eine gute Ergänzung zur Einheitsteststrategie.
Verhaltens-basierte Tests überstehen Refaktorisierungen
Eine zuverlässige Suite sollte es Ihnen ermöglichen, interne Strukturen ohne die Hälfte der Tests neu zu schreiben. Der einfachste Weg, um dorthin zu gelangen, ist, beobachtbares Verhalten anstatt Implementierungsdetails zu behaupten.
Verwendungsfälle, die gut halten:
- Randbedingungen wie leerer Eingabewert, nullartige Werte, ungültige Typen und überdimensionierte Zeichenketten
- Ausgänge des Domänenbereichs wie z.B. "Zugriff verweigert, da die Berechtigung fehlt"
- Zustandsübergänge wie z. B. 'Markiert als ausstehend nach dem Download der Metadaten wird überprüft'
Anwendungsfälle, die oft verrotten:
- Internen Hilfsfunktionen untersuchen
- Private Methodenfolgen behaupten
- Jedes Schicht in der Aufrufkette mocken
Für App-Teams, die disziplinierte Releaseprozesse aufbauen, ist der Artikel von Capgo zu "Qualitätssicherung von Apps" nützlich, weil er die Testarbeit mit dem breiteren Releasepipeline verbindet. Testen für CI, __CAPGO_KEEP_0__, und Electron-Apps Ein Test, der nur auf einem Entwickler-Computer läuft, ist kein Sicherheitsnetz. Es ist eine lokale Gewohnheit.
CI wandelt JavaScript-Testarbeiten in Team-Infrastruktur um. Jeder Push, Pull-Request oder Releasezweig kann die gleichen Befehle mit den gleichen Erwartungen ausführen. Diese Konsistenz ist noch wichtiger für Capacitor- und Electron-Projekte, bei denen sich Umgebungsdrift zu subtilen Fehlern verhält.
State transitions
CI turns unit tests JavaScript work into team infrastructure. Every push, pull request, or release branch can exercise the same commands with the same expectations. That consistency matters even more for Capacitor and Electron projects, where environment drift causes subtle failures.
Machen Sie CI zum Standardausführungspfad
Mindestens sollte Ihre CI-Instanz Abhängigkeiten installieren und die Einheitssuite auf jedem Änderungssatz ausführen. Halten Sie den Befehl so weit wie möglich identisch zum lokalen Entwicklungsumfeld.
Ein grundlegender GitHub Actions-Auftrag kann so klein wie folgt sein:
name: test
on: [push, pull_request]
jobs:
unit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm ci
- run: npm testDas reicht aus, um fehlerhafte Importe, fehlgeschlagene Behauptungen und unbeabsichtigte Plattformannahmen vor dem Hineinlaufen in die Hauptversion zu erkennen.
Für mobile Teams, die über automatisierte Pipelines liefern, bietet Capgo eine praktische Anleitung zum Einrichten von CI/CD für Capacitor-Anwendungen.
Testen von Capacitor-Plugininteraktionen
Die falsche Art, Capacitor-code zu testen, ist, native Plugins direkt in jede Dienstinstanz zu pullen. Das verbindet Ihre Testsuite mit der Plattformbrücke.
Die bessere Muster ist eine dünne Abstraktion:
// deviceStorage.js
async function saveFile(filesystem, path, data) {
return filesystem.writeFile({ path, data });
}
module.exports = { saveFile };// draftService.js
async function persistDraft(storage, draft) {
await storage.save('draft.json', JSON.stringify(draft));
return { saved: true };
}
module.exports = { persistDraft };// draftService.test.js
const { persistDraft } = require('./draftService');
test('persists a serialized draft', async () => {
const storage = {
save: jest.fn().mockResolvedValue(undefined)
};
const result = await persistDraft(storage, { title: 'Hello' });
expect(result).toEqual({ saved: true });
});Die gleiche Idee gilt für die Kamera-Zugriff, die biometrischen Anfragen, die Push-Token-Registrierung und den Netzwerkstatus. Halten Sie die Pluginaufrufe in Adapters.
Testen von Electron-Hauptrenderer und IPC code
Elektron-Anwendungen haben zwei wichtige Scharniere: Hauptprozess code und Renderer-Prozess code. Verschwimme sie in Tests nicht.
Ein zuverlässiger Setup trennt normalerweise:
- Eineinheitstests für Renderer zur Sichtbarkeit von Modellen, Zustand, Formatierung und Geschäftslogik auf der Benutzeroberfläche
- Eineinheitstests für den Hauptprozess zur Menüverwaltung, Dateibearbeitung und Entscheidungen zum Lebenszyklus der App
- Vertragsprüfungen für IPC zur Form und erwarteten Antworten der Nachrichten
Beispiel für eine IPC-Abdeckung:
// ipcGateway.js
function sendSettings(ipcRenderer, payload) {
ipcRenderer.send('settings:update', payload);
}
module.exports = { sendSettings };// ipcGateway.test.js
const { sendSettings } = require('./ipcGateway');
test('sends settings update over ipc', () => {
const ipcRenderer = { send: jest.fn() };
sendSettings(ipcRenderer, { theme: 'dark' });
expect(ipcRenderer.send).toHaveBeenCalledWith('settings:update', { theme: 'dark' });
});Wenn Sie die Implementierung eines Helfers später in einen anderen ändern, hält diese Prüfung noch immer, da sie die verifiziert, die sich auf das Verhalten auswirkt, das zählt. Das ist der Standard, den Sie sich auf Desktop- und Mobilgeräten wünschen code.
Häufig gestellte Fragen zu JavaScript-Einheitstests
Was ist der Unterschied zwischen Einheitstests, Integrations- und E2E-Tests
A Ein Einheitstest prüft einen kleinen Teil der Logik in Isolation. Ein Integrations-Test prüft, ob einige Komponenten oder Dienste korrekt zusammenarbeiten. Ein End-to-End-Test übt eine Benutzerreise durch die laufende Anwendung aus.
Verwenden Sie Einheitstests für schnelles Vertrauen in Geschäftsregeln. Verwenden Sie Integrations-Tests für Scharniere wie Speicher, Plugin-Wrapper und IPC. Verwenden Sie E2E-Tests sparsam für die Workflows, die sich ernsthaft negativ auswirken würden, wenn sie fehlschlagen.
Sollten wir uns auf eine vollständige Abdeckung richten
Keine. Eine umfassende Abdeckung kann Teams dazu treiben, sich auf niedrigwertige Tests zu konzentrieren.
Die Abdeckung ist nützlich, wenn sie riskante code offenlegt, die niemand ausprobiert hat. Sie ist nicht nützlich, wenn Ingenieure nur flache Behauptungen hinzufügen, um ein Dashboard zu befriedigen. Wenn Ihr Suite anfällig ist, wird mehr Abdeckung es nicht retten.
Wie fügen wir Tests zu einem bestehenden Codebase hinzu
Beginnen Sie dort, wo Änderungen bereits stattfinden. Ersticken Sie das Team nicht und kündigen Sie einen riesigen Überarbeitungsplan für die Teststrategie an.
Ein praktischer Ablauf sieht wie folgt aus:
- Schützen Sie aktive code zuerst durch Hinzufügen von Tests zu Modulen, die Sie während der Feature-Arbeit oder Bug-Fixes bearbeiten
- Entfernen Sie reine Logik aus schwer zu testenden Dateien, damit Geschäftsregeln ohne Framework- oder Laufzeit-Rauschen getestet werden können
- Fügen Sie Schaltflächen um um native Plugins, Netzwerkclients, Dateisystemaufrufe und Electron-IPC zu umschließen
- Weigern Sie sich gegen anfällige Muster wenn Sie Mocks einführen. Leitfaden zu JavaScript-Testbest Practices sind hier besonders nützlich, da sie das oft übersehene Problem der Über-Mockung und die brüchigen Tests, die folgen, hervorheben
Das Ziel ist nicht die sofortige Vollständigkeit. Es ist ein stetiger Fortschritt in den Bereichen, in denen Rückschritte dem Team am meisten Kosten
Wenn Ihr Team Capacitor oder Elektron-Apps und eine saubere Release-Prozess um JavaScript-Änderungen benötigt, __CAPGO_KEEP_0__ Capgo Geschrieben von
