.NET Unit Tests zum Lesen / Speichern von Daten in der Datenbank

8

Die meisten Dinge, die ich über Komponententests gelesen habe, sind das Testen deiner Klassen und ihres Verhaltens. Aber wie testen Sie das Speichern von Daten in einer Datenbank und das Lesen von Daten aus einer Datenbank? In unserem Projekt erfolgt das Speichern und Lesen von Daten über Dienste, die von einer Flex-Anwendung verwendet werden (mit WebORB als Gateway). Zum Beispiel liest ein Dienst alle Benutzer, die Zugriff auf ein bestimmtes Modul haben. Wie testen Sie, dass die Benutzer, die zurückgegeben werden, tatsächlich die Benutzer sind, die Zugriff auf dieses Modul haben?

Manchmal ist es in der Lage, das Laden von Daten aus der Datenbank zu testen, wenn bereits Daten in der Datenbank vorhanden sind. In einigen unserer Tests müssen wir zuerst eine Menge Testdaten in der Datenbank speichern, bevor wir Lesestoff testen können ...

Dasselbe gilt für Stored Procedures. Wie testen Sie SPs, wenn keine Daten in der Datenbank vorhanden sind? Realität ist, dass wir zum Testen bestimmter gespeicherter Prozeduren Daten in zehn Tabellen benötigen ...

thx, Lieven Cardoen

    
Lieven Cardoen 26.02.2009, 13:55
quelle

7 Antworten

4

Sie können Tests für db-Aktionen durchführen, aber versuchen Sie es möglichst zu vermeiden, andernfalls:

  • Sie werden langsamer als normale Tests ausgeführt (wahrscheinlicher sind sie Integrationstests)
  • Sie benötigen mehr Setup / Teardown-Arbeit (db / schema / table data)
  • Sie führen eine externe Abhängigkeit von Ihrem Testframework ein

Es kann auch ein Code-Geruch sein, dass Ihre Klassen db-verwandte Arbeiten nicht von anderen Arbeiten trennen, z. Geschäftslogik. Es kann jedoch nicht sein, dass wir einen Framework-Test haben, der überprüft, dass das automatisch generierte SQL-Skript nach dem Einfügen neuer Daten den erwarteten inkrementierten Identity-Wert zurückgibt, AFAIK gibt es keine Möglichkeit zu testen, dass dieser Code anders funktioniert, als ihn gegen die Datenbank auszuführen. Du könntest es dir vormachen oder einfach annehmen, dass, wenn das SQL mit dem übereinstimmt, was du erwartest, es in Ordnung ist, aber ich mag diese Annahme nicht, da so viel anderer Code davon abhängt.

Abhängig von Ihrem Test-Framework sollten Sie diese Tests als [Datenbank] -bezogen markieren, damit Sie sie von anderen Tests trennen können.

    
si618 26.02.2009, 14:11
quelle
5

Dies ist mehr ein Integrationstest als ein Komponententest.

Was ich in solchen Fällen mache ist, dass ich einen nicht-persistenten Basis-Test aufbaue, der die für die Tests benötigten Daten in eine test-db lädt und dann die Komponententests ausführt. danach entsorgt es die aktuelle Transaktion, so dass keine Daten gespeichert werden.

Das größte Problem hier ist, dass, wenn Ihr Kunde einen Fehler hat - Sie können solche Tests nicht ausführen ... ein anderes Problem ist, dass die Daten in Ihrer Test-Datenbank jedes Mal zurückgesetzt werden, wenn Sie solche Tests ausführen.

    
Gambrinus 26.02.2009 14:01
quelle
4

Ich stimme @Gambrinus zu. Im Allgemeinen ist es nahezu unmöglich, eine Datenschicht im Unit-Test zu testen. Das Beste, was Sie tun können, ist eine starke Datenschicht-Schnittstelle bereitzustellen und in der Business-Schicht dagegen zu spotten, und dann Datenqualitätstests für Ihre Integrationstests zu speichern.

Ich habe Versuche gesehen, ORM-Tools zu verspotten () diese für LINQ amüsiert mich), aber sie prüfen nicht die Korrektheit einer Abfrage, nur dass die Abfrage so geschrieben wurde, wie der Tester dachte, dass sie geschrieben werden sollte. Da der Tester normalerweise die Abfrage gegen das ORM schreibt, liefert dies keinerlei Wert.

    
Randolpho 26.02.2009 14:11
quelle
2

Versuchen Sie es mit mbunit . Es ist ein .NET-Testframework, mit dem Sie die Datenbank in Ihrer Einrichtung füllen können und dann die Änderungen, die Sie während der Tests an der Datenbank vorgenommen haben, rückgängig machen und die Datenbank wieder in ihren vorherigen Zustand versetzen. Es gibt eine kurze Beschreibung darauf hier .

    
ryeguy 26.02.2009 14:01
quelle
2

Tests für den Code zum Speichern und Lesen von Datenbanken heißen Integrationstests . Sie können einen Datengenerator verwenden, um vor dem Ausführen von Integrationstests Testdaten zu generieren. Integrationstests müssen nicht so oft wie Unit Tests ausgeführt werden.

    
idursun 26.02.2009 14:04
quelle
1

Es ist lustig, ich habe das gleiche Problem bei meinem Projekt. Verspotten ist wahrscheinlich ein guter Weg, aber ich habe es nicht versucht. Im Allgemeinen füllen wir unsere Tabellen mit Daten. Ich schreibe Komponententests, die die CRUDL-Fähigkeiten einer bestimmten Klasse ausüben. Wenn ich also eine Personenklasse habe, werden die Komponententests erstellt, gelesen, aktualisiert, gelöscht und aufgelistet. Diese Methoden rufen (in den meisten Fällen) gespeicherte Prozeduren auf, so dass sie auch diesen Teil testen.

Es gibt Tools, die Bootsladungen von Testdaten ausgeben können.

SQL-Datengenerator von Red Gate

Lassen Sie uns wissen, welcher Ansatz für Sie funktioniert hat.

    
Luis 26.02.2009 14:05
quelle
0
  • A: Wenn FlexApplication direkt auf Ihre Datenbank zugreift, ist es nicht einfach zu testen. Sie sollten eine testbare Schnittstelle / Schicht dazwischen haben.
  • B: Daten in die Datenbank zu legen ist normal in der "TestSetup-Phase".
  • C: Es sollte möglich sein, eine Schnittstelle zu testen, die tatsächlich die gespeicherte Prozedur auslöst.
    • Wenn es sich um Sprocs handelt, die nicht von der GUI benutzt werden, sondern nur von sql-zu-sql, dann sind es auch Systeme, die sprocs testen. Normalerweise haben Sie vor und nach den eigentlichen Tests einen Sp_setup und einen Sp_teardown-Sproc
ThorHalvor 26.02.2009 14:04
quelle

Tags und Links