1. Überblick
- Vorstellung einer Methode zum Aufbau von Unit-Tests im Stil von Sociable Tests (mit echter DB-Anbindung)
- ORMs wie TypeORM haben Probleme bei der Typsicherheit, daher sind Tests mit einer echten DB notwendig
2. Solitary Test vs. Sociable Test
- Vergleich
- Solitary Tests ersetzen Abhängigkeiten durch Mocks und testen isoliert (schnell, aber es können Unterschiede zur realen Umgebung entstehen)
- Sociable Tests testen zusammen mit echten externen Abhängigkeiten (DB) und können so Zuverlässigkeit sicherstellen (langsamer, aber realistische Probleme werden früh erkannt)
- Grenzen von Solitary Tests
- Mit Mocking lassen sich Probleme in der Interaktion mit einer echten DB nur schwer vollständig erkennen
- Durch Probleme bei der Typprüfung in TypeORM können Runtime-Fehler auftreten
- Warum Sociable Tests nötig sind
- Durch die Anbindung an eine echte DB lassen sich komplexe Queries, Transaktionen und Probleme bei Relations prüfen
- Durch das Einrichten einer Testdatenbank können isolierte Tests per Transaktionsverfahren durchgeführt werden
- Vorteile und Hinweise zu DB-Sociable-Tests
- Vorteile: hochzuverlässige Tests, frühes Erkennen von ORM-bezogenen Problemen, Prüfung auf Schema-Abweichungen
- Zu beachten: langsamere Testausführung, komplexere Einrichtung der Umgebung, notwendiges Transaktionsmanagement
3. Umsetzung von DB-angebundenen Tests in NestJS
- Konfiguration
- Einrichten der Verbindung zu einer Test-DB mit MySQL
- Einsatz von Transaktionen, um Änderungen jedes Tests per Rollback zurückzunehmen
- Nutzung des Lifecycles des Jest-Test-Frameworks
- Verwendung von
beforeAll / beforeEach / afterEach / afterAll
- Einrichtung von DB-Initialisierung und -Verbindung sowie Start und Ende von Transaktionen
4. Fazit
- Beim Schreiben von Unit-Tests ist es sinnvoll, Solitary Tests und Sociable Tests passend zu kombinieren
- Zur Vermeidung von ORM-bezogenen Problemen können Sociable Tests eine große Hilfe sein
Noch keine Kommentare.