TDD: Wie teste ich mein Datenrepository?

Erstmal ein lautes HALLO an mycsharp.de,

ich bin erst vor ein paar Tagen auf der Suche nach .NET-Diskussionsstoff über die Seite gestolpert und hoffe hier eine schöne Zeit verbringen zu können. Das wenige was ich bisher von der Seite gesehen habe, gefällt mir gut! 👍

Nun habe ich eine Frage: Ich probiere mich gerade im Test Driven Development, bzw. Unit Testing. Zum isolierten Testen von Business-Klassen habe ich die Datenzugriffe in ein Datenrepository als Interface ausgelagert. Um die Business-Klassen zu testen nutze ich Stubs die notwendige Methoden dieses Interfaces implementieren. Die Businessklassen kann ich also prima testen.

Wie aber teste ich das Datenrepository selber? Muß ich denn nochmal abstrahieren? Wie würde man z.B. ein einfaches Speichern in eine XML-Datei testen, oder das Speichern in eine Datenbank? Das wäre vermutlich schon fast ein Integrationstest, aber ich muß doch trotzdem auch einen Unittest für mein Repository machen können!? 🤔

Wäre schön wenn Ihr mir ein paar Hinweise geben könntet, Links wären auch prima. Am schönsten wäre ein Beispielsource.

gruß,
alx

hallo alx,

konkreten beispielcode darf ich dir leider nicht geben, aber bei uns in der firma machn wir folgendes.

Wir lassen uns einfach aus unseren Mappings (fluent Nhibernate und xml-Mappings) eine Datenbank erstellen (kann man natürlich auch per script machen, aber so ist halt schöner) und testen unsere Repositorys dann gegen diese Datenbank. Vorher haben wir das ganze mal mit SQLite probiert, das gab aber probleme, weil es sich in einigen belangen anders verhält als der "große" SQLServer und auch die 32 und 64 Bit-version dort nicht so 100% übereinstimmen.

schöne grüße
Craze

Hallo

Die große Frage ist was an dem Reporistory willst du testen ?

Unter Repositoring verstehe ich eine Sammlung an Entitäten die keine eigenständige Funktion haben.

Oder geht es bei dir um die Datenanbindung an sich wegen SQLDialekt Unterschiede etc?

Generell würde ich (sofern möglich ) Entitäten ,Funktion und Datenbindung trennen und dann ganz wichtig jedes getrennt testen

Hallo Craze, hallo Haggy,

vielen Dank für Eure Antworten.

@Craze: Jo, das funktioniert. Ist aber streng genommen dann schon ein Integrationstest bzw. eine enge Kopplung zwischen Test und Datenmodell, oder? Hattet Ihr schonmal den Fall das Ihr größere Änderungen am Datenmodell durchgeführt habt und viele Tests angepasst werden mussten? Ansonsten gefällt mir das mit den Skripten.

@Haggy: Genau das ist der Punkt. Ich habe ja jetzt alles getrennt. Ich kann meine Business-Entitäten an das Repository schicken um sie dort in die DB speicher zu lassen. Ich kann alles getrennt testen. Nur beim Speichern in die DB an sich, muß ich entweder so verfahren wie von Craze beschrieben, oder wie mir jetz in einem anderen Forum vorgeschlagen, die DB-Klassen Stubben/Mocken um zu testen ob die das Repo die DB-Klassen korrekt initialisiert, anspricht, etc.

Ich probier das mal mit dem DB-Stub/Mock aus und werde berichten wie schlimm das war 😉

gruß,
alx

Also an der Datenstruktur scheitert das ganze nicht, weil wir wie gesagt die datenbank für jeden test aus den Mappings erstellen lassen, die DB für den Test ist also immer auf dem aktuellen stand (zusätzlich gibt es auch noch mapping-tests, aber die sind hier ja nicht das thema).
Das ist halt das problem beim script. Ändert sich die datenstruktur musst du auch das script wieder anpassen.

Problem beim stubben der DB-Klassen ist dann wiederrum, das du zwar testen kannst, ob dein Repository was in die DB schreibt, aber ob das ganze auch so gespeichert wird, wie es sein soll weißt du in dem falle leider nicht, da du die daten nicht 1 zu 1 wieder rausholen kannst

Zum erstellen einer TestDB eignet sich NDBUnit besser.