Best Practice Datenbereitstellung Unit Test

[ubuntu_88]

Guten Abend,

ich möchte gerne wissen, wie man Daten für Unit Tests bereitstellt.
Was würdet ihr machen?

Es geht um ein Entwicklungsprojekt mit mehreren Leuten.
Jeder betreibt eine lokale Datenbank, aus der die Daten für die Unit Tests kommen.
So wird keine gleiche Prüfung erreicht, weil die Daten sich lokal unterscheiden können.

Meine beiden Ideen sind, Mockito zu nutzen, und/oder eine Datenbank, die sich nach dem Test wieder zurücksetzt.

Was sind Vorteile und Nachteile?

Danke!

Beste Grüße

 

[Tobse]

Wenn ihr rohe Datenbankabfragen macht würde ich eine SQLite Datenbank empfehlen. Je nachdem ob ihr eure DB-Migrationen automatisiert kann man dann auch ziemlich einfach diese Test-DBs migireren. In diesem Fall macht eine DB pro Test Suite Sinn weil dann der Testfall klarer definiert ist.
Aber wenn die Migrationen händisch ausgeführt werden wird das migrieren der Test-DBs eine s****** Arbeit und Fehleranfällig ist das auch. Dann würde ich eine DB für die Tests nehmen, aber auch SQLite weil man die einfach mit den Testfiles speichern kann (auch im Repo).

Wenn ihr mit einem ORM arbeitet kannst du die nötigen Beans ja auch händisch erstellen und bist damit völlig unabhängig von einer Datenbank.

 

[ubuntu_88]

Wir nutzen JPA ORM.
Was genau meinst du mit den Migrationen?
Welche Vorteile hätten die Test Suites?

Es sind Beans schon erstellt worden. Würde man dann ein "Repository" erstellen und davon eine Mock Klasse ableiten https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&uact=8&ved=0CDoQFjAE&url=http%3A%2F%2Fwww.ipd.uka.de%2FTichy%2Fuploads%2Ffolien%2F164%2F04Mock-Objekte.pdf&ei=wWZ0VevcE4TmyQOMn4CADg&usg=AFQjCNHUsWOW65PsXwkDHij2X--joLS2Tw&sig2=swNcpZ4OK6ucv-y_6Kq6dQ, Seite 3.
Mit einer weiteren Klasse würde man dann das Repository mit einer Mock Factory (Patterns For Better Unit Testing With JPA | Javalobby) füttern, oder?

Besonderes wichtig sind auch qualitativ und quantitativ gute Testdaten.
Wie kommt ihr an solche?

 

[Tobse]

Mit Migrationen meine ich Änderungen an der Datenbank. Neue Felder, neue Tabellen, änderungen von Datentypen, Indizes, alles was sich ändern kann.

Mit den Beans habe ich mich vllt nicht richtig ausgedrückt. Die Klassen gibt es selbstverständlich schon, ich meinte die Objekte. In den Beiden Links wird genau das gemacht, was ich meinte: Die Instanzen der Beans werden nicht aus der DB geladen sondern direkt im Test-Code erzeugt: User u = new User(24, "Hans");

Wenn es um spezielle Testfälle geht (dass z.B. berechnungen korrekt laufen) konstruiere ich die Testdaten meistens; denn nur so kann man das Ergebnis prüfen, ohne den Code für die Berechnung auch in den Test zu packen (womit der Test obsolet ist).
Wenn es darum geht einfach viele, realitätsnahe Daten zu haben entnehme ich die fast immer der Produktiv-Datenbank. Daten, die da aus Datenschutztgründen nicht "rauskopiert" werden dürfen, "generiere" ich mit eigens dafür gemachten Formeln (z.B. eine Liste mit Einkäufen/Zahlungsbestätigungen oder GPS Daten)

 

[ubuntu_88]

Ok, wie geht man vor, wenn die Testdaten new "User u = User(24, "Hans");" in mehreren Testfällen gebraucht wird?

 

[Tobse]

Über das MockRepository. z.B.

// Applikationscode
public User[] getFriends()
{
    // ORM benutzen um alle User -> User Beans zu bekommen, welche Freunde von this sind.
}

// Testcode
public User[] getFriends()
{
    return new User[]{new User(4, "Hans"), new User(3, "Bernd")};
}

 

[Maggot]

Vielleicht hilft dir DBSetup weiter. (DbSetup, from Ninja Squad).