Wo die Tests ausgeführt werden

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.

</ph>

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.
• 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

• Was sind die Vorteile von nächtlichen Builds?

Wissen testen