2016-04-21 12 views
0

Ich habe eine Funktion zum Konfigurieren der Audit-Funktion der Anwendung (MySQL-Datenbanken). Hier ist, was es tut: - erhalten alle Datenbanktabellen Struktur - erstellen Audit-Tabelle entspricht (oder vorhandene ändern) - neu Haupttabelle löst erfassen alle DatenWie DDL-Änderung zu testen

ändern

Jetzt bin ich darüber nachzudenken, wie die Prüfung der schreiben Dies. Ich habe Live-Integrationstest erstellt, indem ich die Datenbankstruktur geändert habe, diese Audit-Konfigurationsanzeige ausgeführt habe und ihre Richtigkeit überprüft habe, aber dies ist nicht der Test, den ich in die Anwendung aufnehmen kann (sie modifiziert die echte Datenbank). Ist es tatsächlich möglich, diese Funktion zu testen, und wenn ja? Wie man die DDL Änderung nachahmt und überprüft?

+0

Können Sie es in Ihren Komponententests gegen eine In-Memory-Datenbank wie Derby ausführen? – DaveH

+0

Nein, kann ich nicht. Die DDL-Syntax ist ziemlich datenbankspezifisch, daher werde ich nicht ohne Änderungen in einer anderen Datenbank laufen. Ich habe H2 bisher probiert und es schlägt fehl. – smoczyna

+0

Ich kann mir vorstellen, nur eine Möglichkeit, es jetzt zu testen, nämlich die Anzahl der Tabellen, Spalten und Trigger (die Richtigkeit der Audit-Sachen) nach der vollständigen Installation zu überprüfen. Es testet das Ergebnis eher als die Funktionalität selbst, aber das ist besser als nichts. – smoczyna

Antwort

0

Um dies zu erledigen, habe ich mich entschieden, stattdessen die Abfragegenerierung (ihre Korrektheit) zu testen. Ich extrahierte alle SQL-Anweisungen (statisch und dynamisch) in separate Methoden und verwendete dann partielles Mockito (Mockito), um diese Methoden auszuführen und zu prüfen, ob sie SQL-Anweisungen wie erwartet erzeugten. Auf diese Weise muss ich nichts in Echt laufen lassen und habe immer noch 90% der Berichterstattung, was das eigentliche Ziel war. Der Hauptteil bestand darin, alle SQL-Aufrufe von der Hauptmethode zu trennen, um partielles Mocking zu ermöglichen.