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 verschlimmern in Capacitor und Electron Apps. Ein einfaches Feature kann gemeinsame Geschäftslogik, Browser-APIs, native Plugins, lokale Dateien, IPC und Remote-Dienste in einem Flow berühren. Wenn Sie diese Teile falsch testen, wird Ihr Suite zu einem Labyrinth aus fiktiven Abhängigkeiten. Wenn Sie sie richtig testen, erhalten Sie schnelles Feedback auf die Logik, die bricht.
Gute Einheitstests für JavaScript beginnen nicht mit cleverer Matcher-Syntax. Sie beginnen mit einer disziplinierten Grenze: Testen Sie reine Logik direkt, isolieren Sie Nebeneffekte und vermeiden Sie es, Tests zu schreiben, die zusammenbrechen, wenn Sie einen internen Funktion umbenennen.
Inhaltsverzeichnis
- Die Wahl Ihres JavaScript-Testframeworks
- Projektsetup und Ihre erste Test
- Meisterung von Mocks und asynchronen Code
- Fortgeschrittene Strategien für robuste Tests
- Testen Sie für CI, Capacitor, und Electron-Apps
- 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 skalieren nicht, wenn mehrere Ingenieure an demselben Codebase arbeiten. Sie benötigen Testentdeckung, Assertions, 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 Auswahl an Mainstream-Optionen. Jest, Mocha und Jasmine werden wiederholt als Hauptframeworks hervorgehoben, mit Jest oftmals für die integrierte Teststruktur, -anweisungen, -Mocking und asynche Unterstützung in einem Paket hervorgehoben, wie in diesem Pluralsight-Lab für JavaScript-Tests.
Warum ein Framework nicht optional ist
Das erste Missverständnis, das Teams haben, ist, dass Einheitstests eine Nebentätigkeit sind. Das führt normalerweise zu inkonsistenten Dateinamen, eigenen -Anweisungen, die niemand mehr kennt, und Helfern, die nur einer Person bekannt sind
Ein Framework gibt dir eine gemeinsame Sprache:
- Teststruktur mit
describeodertestAnsprücheit - mit lesbarer Vergleichsmöglichkeit with
- Hooks für die Einrichtung und den Abbau
- Async-Unterstützung für Versprechen und Timer
- Tools zum Mocken für externe Abhängigkeiten
Wenn Ihr Team auch einen umfassenderen Überblick über die Automatisierung von Tests benötigt, der über die Einheitsebene hinausgeht, hat Capgo einen nützlichen Überblick über Automatisierte Tests in Lieferflüssen von Anwendungen.
Jest vs Mocha im Überblick
Jest und Mocha vertreten zwei unterschiedliche Philosophien.
Jest ist die alles-in-einem-Option. Sie liefert am ersten Tag die meisten Dinge, die Teams benötigen.
Mocha ist modularer. Es bietet einen Runner und erwartet, dass Sie den Rest der Stacks zusammenbauen.
| Funktion | Jest | Mocha |
|---|---|---|
| Setup-Komplexität | Niedriger für die meisten Teams | Höher, da Sie normalerweise Assertion- und Mocking-Bibliotheken hinzufügen |
| Ansprüche | Inbegriffen | Normalerweise mit einer anderen Bibliothek kombiniert |
| Mocking | Integriert in | Normalerweise mit einer anderen Bibliothek kombiniert |
| Asynchrone Tests | Integriert und direkt | Unterstützt, aber hängt mehr von der Umgebung ab |
| Abdeckungsworkflow | Häufig in die gleiche Werkzeugkette integriert | Oft mehr zusammengefügt |
| Beste Wahl | Neue Projekte, Teams, die Konsistenz wollen | Legacy-Stacks, Teams, die modularen Kontrol haben wollen |
Praktische Regel: Wenn Ihr Team fragen muss, welche Anforderungs- und Mocking-Bibliothek mit dem Runner kombiniert werden soll, wollen Sie wahrscheinlich Jest.
Wie ich es für die meisten Teams empfehle
Für die meisten modernen Projekte würde ich wählen Jest es sei denn, das Codebase hat bereits starke Gründe, sich an Mocha zu halten. Diese Empfehlung wird stärker, wenn die Anwendung Capacitor Da diese Projekte bereits genug Komponenten haben, reduziert sich das Testwerkzeug-Sprawl schnell. Mocha macht noch immer Sinn in älteren Node.js-Diensten oder langlebigen Codebases, wo das umliegende Ecosystem bereits abgeschlossen ist. Aber für einen mittelständischen Ingenieur, der von vorneherein eine robuste Suite einrichtet, entfernt Jest normalerweise mehr Hindernisse als es schafft.Eines wichtigen Umfangsmerkmals ist zu beachten. 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 geeignet, nicht für die schnelle innere Schleife, in der die Einheitstests JavaScript arbeiten sollten.
Projektsetup und erste Test
Live-Updates für Electron
Live-Updates für Capacitor
Aufrechterhaltung einer sauberen Testumgebung sollte langweilig sein. Wenn das Hinzufügen des ersten Tests kompliziert erscheint, wird die Suite wahrscheinlich nicht gesund bleiben.
Einfache Jest-Einrichtung
Beginnen Sie mit einem JavaScript-Projekt, das bereits eine package.jsonDann fügen Sie Jest als Entwicklungsabhängigkeit hinzu und verbinden Sie eine Testskript.
{
"scripts": {
"test": "jest"
}
}Das reicht für viele Projekte. Sie können später mehr Konfiguration hinzufügen, wenn Ihr Modulsystem, die Transpilation oder die Struktur Ihres Monorepos es erfordert.
If you’re building a Capacitor app locally and want your dev environment in order before adding tests around shared logic, Capgo’s guide to setting up a Capacitor local environment Anleitung zur Einrichtung eines
Write the test before the code
Schreiben Sie den Test, bevor Sie das Das Test-First-Muster ist nicht nur eine persönliche Vorliebe. Die U.S. Consumer Financial Protection Bureau empfiehlt explizit, den Test zuerst zu schreiben., Testorganisation mit describe und it, und die Definition von Kontrollen um expect(...) Ansprüche in seiner JavaScript-Einheitstestleitfaden.
Dies ist wichtig, weil testgetriebene Änderungen die Art und Weise beeinflussen, wie Sie code gestalten. Funktionen werden kleiner, Abhängigkeiten werden sichtbarer, und Nebeneffekte dringen nicht mehr in Logik ein, die rein bleiben sollte.
Hier ist ein Minimalbeispiel:
// 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
Das Arrange, Act, Assert Muster hält Tests lesbar, selbst wenn sie komplexer werden.
- Arrange Die Eingabe und jede erforderliche Einrichtung.
- Handeln Durch Aufrufen der Funktion.
- Behaupten Auf das Ergebnis.
Angewendet auf einen Validierungs-Helfer:
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 Ablauf beschreiben.
For Capacitor and Electron projects, that discipline matters more because your pure logic often sits next to native or desktop integration code. Keep the business rule testable without the platform runtime, and your first test won’t be your last useful one.
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.
Das ist der Punkt, an dem Mocking hilft. Es gibt Ihnen die Kontrolle über die Grenze, damit der Test sich auf die Entscheidungsfindung Ihres code konzentrieren kann.
Mockgrenzen setzen, nicht alles
Leitfaden für wartbare Tests betont Einzelverhaltensabdeckung und Eine starke Behauptung pro Test, und es warnt auch davor, dass das Übermachen von Mocks die Tests brüchig und eng mit Implementierungsdetails gekoppelt macht, wie in diesem Artikel von TestRail zu wartbaren Einheitstests.
Dass diese Warnung in JavaScript sehr wichtig ist. Teams beginnen oft damit, jeden importierten Modul zu mocken und enden damit, ob Funktionen andere Funktionen in der richtigen Reihenfolge aufrufen, anstatt das echte Verhalten zu testen.
Schlechter Zielwert für einen Mock-lastigen Test:
- ob Hilfsfunktion A Helper B aufgerufen hat
- ob Dienst C Serializer D aufgerufen hat
- ob eine interne private Funktion zweimal aufgerufen wurde
Bessere Zielgruppe:
- Was die Funktion zurückgab
- Ob es eine fehlgeschlagene Abhängigkeit richtig behandelte
- Ob es die Daten in die erwartete Form umgewandelt hat
Ein besseres Muster für Capacitor und Electron code
Bei mobilen und Desktop-Anwendungen bevorzuge ich eine Wrapper-Schicht um native oder Plattform-APIs herum. Dann mocken 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-Schicht. 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.
Ein schneller Überblick hilft, wenn Ihr Team noch normalisiert, wie man Asynchrone Test-Style schreibt:
Testen asynchrone Flüsse ohne Flakkeheit
Verwende async/await bei Tests, wenn das unter Testen code eine Zusage zurückgibt. Es ist klarer als die callback-lastigen Muster 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');
});Auch testen Sie 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 Pfad als auch den hässlichen Pfad. In der Produktion ist der hässliche Pfad meistens der, den die Benutzer merken.
Fortgeschrittene Strategien für Robuste Tests
Eine Testsuite wird nützlich, wenn sie nach dem code noch nützlich bleibt. Das ist schwieriger als das Schreiben einer Menge von Tests, die laufen.
Verwende das Testen als Budget
Eine praktische Anleitung empfiehlt eine 70/20/10 Zuweisung über Einheiten-, Integrations- und End-to-End-Tests, mit Einheitstests, die das schnellste Feedback und die stabilsten Fehler liefern. Die gleiche Anleitung sagt, dass ein vollständiger Einheitstest-Satz idealerweise in unter 10 Sekundenund Prüfungsvorgänge vor dem Commit sollten bleiben unter 5 Sekundennach dieser Offener Replays Testleitfaden.
Ich betrachte das als Budgetwerkzeug, nicht als Religion. Wenn sich die meisten Ihrer Anstrengungen auf End-to-End-Tests konzentrieren, warten Ihre Teammitglieder zu lange auf Feedback. Wenn alles nur Einheitstests sind, werden Sie die realen Systemgrenzen verpassen.
Für eine Capacitor- oder Electron-Anwendung sieht ein gesunder Ausgleich normalerweise so aus:
- Einheitstests für Preislogik, 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, Kaufprozess, Synchronisierung oder Aktualisierungsanfragen
Abdeckung ist ein Leuchtfeuer, nicht ein Ziel
Abdeckungsberichte sind nützlich, wenn sie Ihnen helfen, ungetestete Zweige in wichtigen Logiken zu erkennen. Sie werden schädlich, wenn Teams Deckungszahlen für ihren eigenen Willen verfolgen.
Ein Login-Validator mit sorgfältigen Tests für Randfälle liefert mehr Wert als ein abgedeckter Datei voller trivialer Behauptungen. Das ist besonders wahr für inputreiche code wie Formulare, Parser, Datumlogik und Berechtigungsprüfungen. Wenn Ihr Team die Qualität um die Validierung schwerer UI herum schärft, ist diese Anleitung zu code die Meisterung der Frontend-Formvalidierung Verhaltens-tests überleben Refaktorisierungen
Ein zuverlässiges 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, das beobachtete Verhalten zu behaupten
Beobachtbares Verhalten anstatt Implementierungsdetails. Verwendungsfälle, die gut halten:
Beispiele, die gut halten:
- Grenzwerte wie leerer Eingabe, Null-Werte, ungültige Typen und übermäßige Zeichenketten
- Domänenausgänge wie „Zugriffsverweigerungen aufgrund fehlender Berechtigungen“
- Zustandsübergänge wie „Update als ausstehend markiert, nachdem die Metadaten heruntergeladen wurden“
Verwendungsfälle, die oft verrotten:
- Internen Hilfsfunktionen untersuchen
- Private Methodensequenzierung behaupten
- Jeden Schritt in der Aufrufkette mocken
Für App-Teams, die disziplinierte Release-Prozesse aufbauen, Capgos Artikel über Anwendungsqualitätssicherung ist nützlich, weil es die Testarbeit mit der breiteren Releasepipeline verbindet.
Testen für CI, Capacitor, und Electron-Apps
Ein Test, der nur auf einem Entwicklerrechner läuft, ist kein Sicherheitsnetz. Es ist eine lokale Gewohnheit.
CI wandelt die JavaScript-Einheitstests in Team-Infrastruktur um. Jeder Push, Pull-Request oder Releasezweig kann die gleichen Befehle mit denselben Erwartungen ausführen. Diese Konsistenz ist bei Capacitor- und Electron-Projekten noch wichtiger, da sich die Umgebungsdrift zu subtilen Fehlern verhält.
Machen Sie CI zum Standardausführungspfad
Zumindest sollte Ihre CI die Abhängigkeiten installieren und die Einheitssuite auf jedem Änderungssatz ausführen. Halten Sie den Befehl, wenn möglich, identisch zur lokalen Entwicklung.
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 Imports, fehlende Aussagen und zufällige Plattformannahmen vor der Landung in der Hauptversion zu erkennen.
Für mobile Teams, die durch automatisierte Pipelines liefern, hat Capgo eine praktische Anleitung zum Einrichten von CI/CD für Capacitor-Apps.
Testen von Capacitor-Plugininteraktionen
Die falsche Art, Capacitor-code zu testen, ist, native Plugins direkt in jede Dienstleistung zu pullen. Das koppelt Ihre Testsuite an die Plattformbrücke.
Das 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 Zugriff auf die Kamera, biometrische Anfragen, die Registrierung von Push-Tokens und den Netzwerkstatus. Halten Sie Aufrufe von Plugins in Adapters. Testen Sie die Anwendungslogik gegen Interfaces, die Sie steuern.
Testen Sie den Electron-Hauptrenderer und den IPC code
Elektron-Apps haben zwei wichtige Scharniere: Hauptprozess code und Renderer-Prozess code. Blenden Sie sie in Tests nicht.
Ein zuverlässiger Aufbau trennt normalerweise:
- Renderer-Einheitstests für View-Modelle, Zustände, Formatierungen und Geschäftslogik auf der Benutzeroberfläche
- Hauptprozess-Einheitstests für Menüs, Dateioperationen und Entscheidungen zum Lebenszyklus der App
- IPC-Vertragsprüfungen für die Form der Nachrichten und die erwarteten Antworten
Beispiel für einen IPC-Wrapper:
// 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 später die interne Implementierung von einem Helper zu einem anderen ändern, hält sich dieser Test noch immer, da er die verhaltensrelevanten Aspekte überprüft. Das ist der Standard, den Sie für Desktop- und Mobilgeräte wollen, code.
Häufig gestellte Fragen zum JavaScript-Einheitstesten
Was ist der Unterschied zwischen Einheitstests und Integrationstests
A Ein Einheitstest prüft einen kleinen Teil der Logik in Isolation. Ein Integrationstest prüft, ob einige Komponenten oder Dienste korrekt zusammenarbeiten. End-to-End-Test Übt eine Benutzerreise durch das laufende Anwendungsprogramm aus.
Verwenden Sie Einheitstests für schnelle 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 verletzten würden, wenn sie brachen.
Sollten wir uns auf eine vollständige Abdeckung richten
Nein. Eine vollständige Abdeckung kann Teams dazu zwingen, Tests mit niedrigem Wert zu erstellen.
Coverage is useful when it reveals risky code that nobody has exercised. It’s not useful when engineers add shallow assertions just to satisfy a dashboard. If your suite is brittle, more coverage won’t save it.
Wie fügen wir Tests zu einem bestehenden Codebase hinzu
Beginnen Sie dort, wo Änderungen bereits stattfinden. Erstellen Sie keine riesige Umstellung der Teststrategie und blockieren Sie das Team.
Ein praktischer Sequenz sieht wie folgt aus:
- Protect active code first durch Hinzufügen von Tests zu Modulen, die Sie während der Feature-Arbeit oder Bug-Fixes berühren
- Entfernen Sie reine Logik von schwer zu testenden Dateien, damit Geschäftsregeln ohne Framework- oder Laufzeit-Noise getestet werden können
- Fügen Sie Schaltflächen ein um native Plugins, Netzwerkclients, Dateisystemaufrufe und Electron-IPC umzugehen
- Verweigern Sie bruchige Muster wenn Sie Mocks einführen. Leitfaden aus JavaScript-Testbest Practices ist hier besonders nützlich, da er das oft übersehene Problem der Über-Mockung und die brüchigen Tests, die folgen, hervorhebt
Das Ziel ist nicht die sofortige Vollständigkeit. Es ist eine stetige Verbesserung in den Bereichen, in denen Regressionsfehler dem Team am meisten kosten.
Wenn Ihr Team Capacitor oder Elektron Apps und benötigt einen sauberen Releaseprozess für JavaScript-Änderungen, Capgo Eine Option ist CapacitorJS und Electron-Apps mit Live-Updates, Rollout-Kontrollen und Beobachtbarkeit zu betrachten. Dies ermöglicht es Teams, solide Einheitstests mit einer sicheren Veröffentlichung von Web-Bundle-Änderungen ohne auf jede Korrektur im Store warten zu kombinieren.
