Die Qualitätssicherung (QA) umfasst Prozesse und Werkzeuge, die sicherstellen, dass ein Produkt den Qualitätsstandards entspricht. Dies ist ein entscheidender Faktor für die schnelle und qualitativ hochwertige Entwicklung anspruchsvoller Software.

Leapsome ist eine Performance Management und Engagement-Plattform, die so komplexe Bereiche wie Ziele abdeckt, Performance Reviews, Umfragen zum Engagement und Lernen abdeckt - und das alles auf höchst flexible Weise. Damit unser relativ kleines Team weiterhin schnell ein erstklassiges Produkt entwickeln kann, haben wir unsere QA-Prozesse so weit wie möglich automatisiert.

Leitgedanken

Um sicherzustellen, dass wir weiterhin qualitativ hochwertige Software in großem Umfang entwickeln, konzentrieren wir unsere Qualitätssicherung auf die folgenden Schlüsselkonzepte:

• Kurze Feedback Schleife

Die Tests sollten so schnell ablaufen, dass wir sofort wissen, ob die Fälle erfolgreich waren oder nicht.

• Hohes Maß an Vertrauen

Tests sollten den Ingenieuren die Gewissheit geben, dass der Code in der Produktion nicht unerwartet versagt, wenn ein Fall erfolgreich ist.

• Robuste

Tests sollten nicht ständig kaputt gehen, wenn sie nicht mit Code-Änderungen zusammenhängen (Daten, Race Conditions usw.). Die Ingenieure sollten ihre Zeit nicht damit verbringen, Tests zu reparieren.

• Lose Kopplung an Implementierungsdetails

Wann immer möglich, sollten Tests nicht eng an Implementierungsdetails gekoppelt sein.

Tests sollten letztlich einen Mehrwert für das Produkt bringen, indem sie dessen Qualität sichern, ohne die Geschwindigkeit des Teams zu beeinträchtigen - vielleicht sogar zu erhöhen. Das Hinzufügen, Ändern oder Refactoring von Funktionen sollte nicht mit doppelten Kosten für das Schreiben des Codes und das Reparieren von Tests verbunden sein.

Um dieses Ziel zu erreichen, haben wir, inspiriert von der "Testing Trophy"-Methode von Kent C. Dodds, die folgenden Schritte in unsere QA-Pipeline implementiert:

Linting

Linting kennzeichnet verdächtige Konstrukte (potenzielle Fehler) im Code. Dies ist das allererste Werkzeug, das uns hilft, fehlerfreien Code zu erreichen, da es normalerweise grundlegende Fehler identifiziert und schnell genug ist, um als Pre-Commit-Hook ausgeführt zu werden.

Linting kann auch verwendet werden, um stilistische Fehler zu erkennen, aber wir ziehen es vor, stattdessen mit einem Code-Formatierungswerkzeug zu arbeiten (in diesem Fall Prettier). Aus diesem Grund konzentriert sich unser Linting nur auf Code-Konstrukte.

Linting wird zunächst als Pre-Commit-Hook und dann als Schritt unserer Continuous Integration (CI)-Pipeline durchgeführt. Da unser Stack auf JavaScript basiert, führen wir unser Linting sowohl für den Server- als auch für den Client-Code mit ESLint durch.

Lokale Tests

Da unsere Plattform in mehreren Sprachen verfügbar ist (derzeit Englisch, Deutsch und Französisch), müssen wir immer wieder neue Strings in jede Sprache übersetzen.

Lokalisierungstests garantieren, dass wir in allen von uns unterstützten Sprachen über die erforderlichen Übersetzungsschlüssel verfügen. Ein benutzerdefiniertes Skript analysiert die Übersetzungsdateien und vergleicht sie mit der Originalversion, um sicherzustellen, dass keine Schlüssel fehlen oder überzählig sind.

Dies wird zunächst als Pre-Commit-Hook und dann als Teil unserer CI-Pipeline durchgeführt.

Unit-Tests (Server-Code)

Unit-Tests analysieren die Genauigkeit einer bestimmten Funktion ("Ist die Ausgabe wie erwartet, wenn eine bestimmte Eingabe erfolgt?"). Wir glauben, dass Unit-Tests nur für die Hauptbausteine eines Systems sinnvoll sind - dementsprechend testen wir nur eindeutige, nicht-triviale Hilfsfunktionen, die in unserem Server-Code verwendet werden.

Hier bei Leapsome führen wir Unit-Tests für bestimmte Hilfsfunktionen durch(z. B. unser Backend-Framework), die nicht-triviale Logik enthalten, um sicherzustellen, dass wir unsere Geschäftslogik sicher auf ihnen aufbauen können. Wir sind der Meinung, dass Unit-Tests nur einen winzigen Teil unseres Testprogramms ausmachen sollten. Der größte Teil der Geschäftslogik sollte durch Integrationstests abgedeckt werden.

Die Unit-Tests werden mit Mocha ausgeführt, mit Chai als Assertion-Bibliothek.

Wenn möglich, sollten Unit-Tests nur eine einzige Funktion untersuchen und alle Nebeneffekte simulieren.

Ein guter Einheitstest sollte diese Fragen beantworten:

1. Was ist die zu testende Einheit (Modul, Funktion, Klasse, was auch immer)?
2. Was sollte sie tun?
3. Wie hoch war die tatsächliche Leistung?
4. Was war das erwartete Ergebnis?
5. Wie können Sie den Fehler reproduzieren?
   

Wir haben zum Beispiel eine Funktion in unserem Code, die eindeutige, schwer zu erratende Bezeichner für einige unserer Ressourcen erzeugt. Wir können Unit-Tests für diese Funktion wie folgt schreiben:

Einheitstests (Client-Code)

Die vorherige Definition von Unit-Tests für den Server-Code gilt auch für den Client-Code.

In diesem Fall führen wir Unit-Tests für Routen, Speicher, Hilfsfunktionen (utils) und Komponenten durch, die die Grundlage für unsere Benutzeroberfläche (UI) bilden. Unit-Tests sollen sicherstellen, dass die Bausteine unserer Benutzeroberfläche solide sind.

In den meisten Fällen versuchen wir, Funktionen isoliert zu testen, indem wir externe Abhängigkeiten (wie den Router oder den Speicher) nachbilden. In seltenen Fällen führen wir auch Snapshot-Tests für Darstellungskomponenten durch.

Wir versuchen, die Verwendung von Snapshot-Tests auf ein Minimum zu beschränken, da sie per definitionem eng mit Implementierungsdetails verbunden sind.

Lediglich einfache Darstellungskomponenten sollten zusätzlich zu den herkömmlichen Testaussagen in Form von Snapshots getestet werden.

Unit-Tests werden mit jest und vue-test-utils durchgeführt.

Auf der Client-Seite können Unit-Tests verschiedene Formen annehmen:

• Helper-Funktionen werden ähnlich wie serverseitige Unit-Tests getestet;
• Routen werden schema-validiert (um sicherzustellen, dass sie innerhalb der erwarteten Parameter existieren);
• Shops werden getestet, indem API-Aufrufe bei Bedarf nachgeahmt werden;
• Die Komponenten werden oberflächlich montiert oder per Snapshot getestet (ggf. werden auch Routes, Props und Store nachgebildet).

Bei der Prüfung von DOM-Elementen in Komponenten referenzieren wir sie über data-test-*-Attribute, um den Test nicht mit dem eigentlichen DOM-Element oder anderen Attributen zu verknüpfen, die sich möglicherweise ändern könnten (wie class oder id).

Die meisten unserer Client Code Unit Tests folgen den Richtlinien des Vue Testing Handbooks.

Integrationstests

Unit-Tests eignen sich hervorragend zum Testen isolierter Funktionen. Da Software jedoch immer komplexer wird, verringert das Mocking von Seiteneffekten das Vertrauen, dass jedes Teil in der Produktion wie erwartet funktioniert.

Ein besserer Ansatz für das ganzheitliche Testen einer komplexen Softwareanwendung ist das Schreiben von Integrationstests. Anstatt nur die Ausgabe einer einzelnen Funktion zu prüfen, testen wir auch (und vor allem) die Nebeneffekte komplizierter Codestücke.

Wenn wir von Integrationstests sprechen, betrachten wir ausschließlich alles, was auf der Serverseite passiert, von den API-Endpunkten an (Handler, Geschäftslogik, Datenbank).

Wir testen weder die API-Schicht noch die Integration mit dem Client (die durch End-to-End-Tests abgedeckt wird).

Integrationstests ermöglichen ein hohes Maß an Vertrauen bei geringer Code-Kopplung. Dies erleichtert das Refactoring und die Weiterentwicklung des Codes und stellt gleichzeitig sicher, dass er weiterhin die erwartete Leistung erbringt. Es garantiert auch, dass die Geschäftslogik im Backend korrekt ist und bietet gleichzeitig genügend Flexibilität für Wachstum und Refactoring.

Das Testen von Seiteneffekten bedeutet in diesem Fall, dass unsere Geschäftslogik die richtigen Daten generiert und manipuliert, da wir meist als Seiteneffekt von Handlerfunktionen in die Datenbank schauen.

Wie Unit-Tests werden auch Integrationstests mit Mocha (plus Chai als Assertion-Bibliothek) durchgeführt.

Um eine saubere Testumgebung zu gewährleisten, führen wir Integrationstests auf Docker gegen eine saubere MongoDB-Instanz durch. Um die programmatische Erstellung von Daten zu erleichtern, stellen wir im Ordner /fixtures Fixtures bereit, die auf Vorlagen (im Ordner /Vorlage ) zugreifen können.

Schauen wir uns zum Beispiel an, wie wir unsere Ziel-Zyklus Funktionalität testen:

• Einfuhren
  

• Globale Einrichtung

• Initialisierung für Ziel-Zyklen

• Testfälle

Integrationstests eignen sich besonders gut zum Testen von Anwendungsfällen. In diesem Fall überprüfen wir, ob ein Ziel-Zyklus eingefroren ist und nicht mit neu erstellten Zielen verknüpft werden kann.

End-to-End-Tests

Während Integrationstests alles betrachten, was jenseits des API-Endpunkts passiert (Handler, Datenbank), verfolgen End-to-End-Tests einen noch ganzheitlicheren Ansatz und untersuchen das Produkt aus der Sicht des Benutzers.

In diesem Fall konzentrieren sich die End-to-End-Tests nicht auf das Testen der Benutzeroberfläche. Es handelt sich eher um funktionale Tests, die sicherstellen, dass sich das Produkt für den Benutzer wie erwartet verhält.

Unit-Tests stellen sicher, dass eine Funktion die erwartete Ausgabe liefert; Integrationstests prüfen, ob Handler die erwarteten Nebeneffekte erzeugen; End-to-End-Tests verifizieren, dass sich das Produkt ganzheitlich so verhält, wie es aus Sicht des Benutzers erwartet wird.

Wir führen End-to-End-Tests auf Cypress durch.

Um eine saubere Testumgebung zu erhalten, wird jede Suite mit einem neu angelegten Konto durchgeführt. 

Dazu verwenden wir den folgenden Befehl als beforeEach- und afterEach-Hook global aus support/index.js:

Wir verwenden Aufgaben, um das Schreiben von idiomatischen Tests zu erleichtern. Um zum Beispiel Benutzer in einer Testsuite zu erstellen, verwenden wir eine createUser-Aufgabe:

Um sicherzustellen, dass unsere End-to-End-Tests nicht eng an die Benutzeroberfläche gekoppelt sind, verwenden wir ausschließlich data-test-id-Attribute zur Auswahl von DOM-Elementen.

Manuelle Tests

Obwohl wir so viel Automatisierung wie möglich anstreben, gibt es nichts Besseres, als das Produkt lokal zu starten und die neuen Funktionen, die wir entwickelt haben, manuell zu testen! :)

Wie Sie sehen können, nehmen wir die Qualitätssicherung bei Leapsome ernst!

Jedes technische Projekt, das wir in Angriff nehmen, ist darauf ausgerichtet, unser Ziel zu erreichen, die Arbeit für alle Menschen erfüllender zu machen, und die Fähigkeit, schnell hochwertige Funktionen zu entwickeln, entspricht diesem Ziel.

- Übrigens, wir stellen ein!