Automatisierte Tests können in der Regel durch manuelles Ausführen eines Skripts oder mithilfe eines Hilfsprogramm aus einem Test-Framework, das oft als Test-Runner bezeichnet wird, Tests durchführen. Sie müssen Ihre Skripts jedoch nicht immer manuell ausführen. Es gibt eine Reihe von Möglichkeiten, Tests durchzuführen, um Feedback zu geben an verschiedenen Punkten des Entwicklungszyklus.
Voraussetzung
Webprojekte haben normalerweise eine Konfigurationsdatei (die Datei package.json
), bei der es sich um
npm, pnpm, Bun o. ä. eingerichtet werden. Diese Konfigurationsdatei enthält Ihre
Projektabhängigkeiten und andere Informationen
sowie Hilfsskripts enthalten. Diese
Hilfsskripts können Informationen zum Erstellen, Ausführen oder Testen Ihres Projekts enthalten.
In package.json
müssen Sie ein Skript namens test
hinzufügen, das
wie Sie Ihre Tests durchführen. Das ist wichtig, denn wenn Sie npm oder ein ähnliches
das "Test"-Tool hat eine besondere Bedeutung.
Dieses Skript kann einfach auf eine einzelne Datei verweisen, die eine Ausnahme auslöst:
etwa node tests.js
. Wir empfehlen aber, sie so zu verwenden, dass sie auf eine
Test-Runner entwickelt.
Wenn Sie Vitest als Test-Runner verwenden,
package.json
-Datei sieht so aus:
{
"name": "example-project",
"scripts": {
"start": "node server.js",
"test": "vitest --run"
}
}
Wenn Sie npm test
mit dieser Datei ausführen, werden die Standardtests von Vitest einmal ausgeführt. In
Vitest: Standardmäßig werden alle Dateien gesucht, die auf „.test.js“ enden oder
und führen sie aus. Je nach
Test-Runner gewählt haben, kann der Befehl etwas anders aussehen.
Wir haben uns für Vitest entschieden, ein zunehmend beliebtes Test-Framework, in diesem Kurs. Weitere Informationen diese Entscheidung in Vitest als Test-Runner auszuführen. Denken Sie jedoch daran, dass Test-Frameworks und -Runner – selbst in verschiedenen Sprachen.
Manueller Testaufruf
Manuelles Auslösen Ihrer automatisierten Tests (z. B. Verwendung von npm test
im
Beispiel) kann nützlich sein, wenn Sie aktiv an einer Codebasis arbeiten.
Das Schreiben von Tests für eine Funktion während der Entwicklung dieser Funktion kann Ihnen helfen,
Vorstellung davon, wie die Funktion
funktionieren sollte – dies berührt das Konzept
test-driven Development (TDD).
Test-Runner haben in der Regel einen kurzen Befehl, mit dem Sie einige oder
alle Tests und eventuell einen Watcher-Modus, der Tests wiederholt, während Sie speichern.
. Das sind alles hilfreiche Optionen bei der Entwicklung einer neuen Funktion.
eine neue Funktion, Tests oder beides zu entwickeln,
durch schnelles Feedback. Vitest beispielsweise arbeitet standardmäßig im Watcher-Modus:
sucht der Befehl vitest
nach Änderungen und führt alle gefundenen Tests noch einmal aus. Mi.
empfehlen, dieses Fenster während des Schreibens
in einem anderen Fenster geöffnet zu lassen,
um bei der Entwicklung Ihrer Tests ein schnelles Feedback zu erhalten.
Bei einigen Runnern können Sie Tests in Ihrem Code auch als only
markieren. Wenn Ihr Code
only
Tests enthält, werden beim Ausführen von Tests nur diese Tests ausgelöst,
was die Testentwicklung beschleunigt und Fehler behoben wird. Selbst wenn alle Ihre
Tests schnell abgeschlossen werden. Mit only
können Sie Ihren Aufwand reduzieren und
die Ablenkung von Tests, die nichts mit der Funktion
oder dem Test zu tun haben, an dem Sie gerade arbeiten.
Bei kleinen Projekten, insbesondere Projekten mit nur einem Entwickler, können Sie auch die gesamte Testsuite Ihrer Codebasis regelmäßig auszuführen. Dies ist besonders hilfreich, wenn Ihre Tests klein und schnell (in keiner Tests durchführen, um sicherzustellen, dass bevor Sie fortfahren.
Tests im Rahmen des Vorabsendens oder der Überprüfung durchführen
Viele Projekte bestätigen,
dass eine Codebasis ordnungsgemäß funktioniert,
Code wird wieder mit seinem main
-Zweig zusammengeführt. Wenn Sie noch keine Erfahrung mit Tests haben,
an Open-Source-Projekten mitgewirkt haben,
Teil des Pull-Anfrageprozesses (PR) bestätigt, dass alle Tests des Projekts
übergeben, d. h. dein neuer Beitrag hat sich nicht negativ auf die
bestehenden Projekts.
Wenn Sie Ihre Tests lokal ausführen, ist das Online-Repository Ihres Projekts (z. B. GitHub oder ein anderer Code-Hostingdienst) nicht erkennt, ob die Tests bestanden wurden. Durch Tests als Aufgabe zum Vorabsenden wird allen Mitwirkenden klar, dass alles funktioniert.
In GitHub werden diese als „Statusprüfungen“ bezeichnet. die Sie über die
GitHub-Aktionen. GitHub-Aktionen sind
im Grunde eine Art von Test: Jeder Schritt muss erfolgreich sein (nicht fehlschlagen oder eine
Error
) bis die Aktion abgeschlossen ist. Sie können Maßnahmen auf alle PRs für ein Projekt anwenden,
und für ein Projekt kann festgelegt werden, dass Aktionen bestanden werden müssen, bevor Sie Code beitragen. GitHub-Datei
Die Node.js-Standardaktion führt npm test
als einen ihrer Schritte aus.
Mit diesem Testansatz wird sichergestellt, dass Ihre Codebasis immer "grün" ist. indem Sie Code, der seine Tests nicht erfolgreich ausführt, nicht akzeptieren.
Tests im Rahmen der kontinuierlichen Integration ausführen
Sobald Ihre grüne PR akzeptiert wurde, führen die meisten Codebasen erneut Tests durch,
dem main
-Zweig Ihres Projekts anstelle der vorherigen PR-Abteilung. Das kann passieren,
sofort oder regelmäßig (z. B. stündlich oder jede Nacht) erfolgen. Diese
werden die Ergebnisse oft als Teil eines Continuous Integration-Dashboards (CI) angezeigt,
den Gesamtzustand des Projekts.
Dieser CI-Schritt kann redundant wirken, insbesondere bei Projekten mit kleiner Codebasis. die bei der Überprüfung bestanden wurden, sodass sie bestehen sollten, sobald eine Änderung vorgenommen wurde. Sie können jedoch aber das stimmt nicht immer. Ihre Tests können auch nach erfolgreichem Abschluss plötzlich fehlschlagen zu grünen Ergebnissen führen. Dies kann unter anderem folgende Gründe haben:
- Mehrere Änderungen wurden "gleichzeitig" akzeptiert, manchmal auch als Race-Bedingung bezeichnet. und sich gegenseitig auf subtile, noch nicht getestete Weise beeinflussen.
- Ihre Tests sind nicht reproduzierbar oder "instabil" können beide Seiten
und schlagen ohne Änderungen am Code fehl.
- Dies kann vorkommen, wenn Sie von Systemen außerhalb Ihrer Codebasis abhängig sind. Für eine
Proxy, stellen Sie sich vor, dass
Math.random() > 0.05
getestet wird – dies würde zufällig 5 % fehlschlagen lassen der Zeit.
- Dies kann vorkommen, wenn Sie von Systemen außerhalb Ihrer Codebasis abhängig sind. Für eine
Proxy, stellen Sie sich vor, dass
- Einige Tests, z. B. End-to-End-Tests, sind zu kostspielig oder zu teuer für jede PR durchzuführen. Tests (weitere Informationen finden Sie unter Arten automatischer Tests) und können im Laufe der Zeit kaputtgehen, ohne immer zu benachrichtigen.
Keines dieser Probleme lässt sich überwinden, aber es ist es wert, Tests und Softwareentwicklung im Allgemeinen Wissenschaft.
Ein Zwischenspiel zum Rollback
Wenn Tests im Rahmen der kontinuierlichen Integration ausgeführt werden und selbst wenn Tests Statusprüfung ausgeführt wird, ist es möglich, dass der Build in einer oder ein anderer Status für fehlgeschlagene Tests. Wie bereits erwähnt, Das kann verschiedene Gründe haben, z. B. Race-Bedingungen während des Tests. oder instabilen Tests.
Bei kleineren Projekten könnten Sie instinktiv vorgehen, um sie als Krise zu betrachten. Anhalten alles rückgängig machen, ein Rollback der betreffenden Änderung durchführen und eine bekannte guten Zustand. Dies kann ein sinnvoller Ansatz sein, aber es ist wichtig, zu bedenken, Tests (und Software im Allgemeinen!) sind ein Mittel zum Zweck, kein Ziel selbst. Ihr Ziel ist wahrscheinlich, Software zu entwickeln und nicht alle Tests zu bestehen. Stattdessen können Sie Forward einführen, indem Sie die funktionsgefährdende Änderung mit einer weiteren Änderung, mit der die fehlgeschlagenen Tests behoben werden.
Andererseits haben Sie vielleicht große Projekte gesehen oder daran gearbeitet, in einem ständig kaputten Zustand ist. Schlimmer noch, das große Projekt hat einen instabilen Test, macht häufig genug Pausen, um Ermüdung des Alarms zu verursachen. für Entwickler. Dies ist für Führungskräfte oft ein existenzielles Problem: können sogar deaktiviert sein, weil sie als „Hindernisse für Entwicklung“.
Es gibt keine schnelle Lösung dafür, aber es kann helfen, selbstbewusster zu schreiben Tests (Verbesserung) und den Umfang der Tests zu reduzieren (Vereinfachung), damit leichter identifiziert werden können. Erhöhte Anzahl von Komponententests oder Integrationstests. Weitere Informationen zu Typen finden Sie unter Arten automatischer Tests) können die Zuverlässigkeit als einen großen End-to-End-Test, der sich nur schwer durchführen lässt und der alles auf einmal.
Ressourcen
Wissen testen
Wie heißt das spezielle Skript, das npm und ähnliche Programme auf die Sie beim Testen achten?