Wie testen Sie eine Einheit, die mit Daten kommunizieren soll?

Question

Ich habe ein paar Repository-Klassen, die mit verschiedenen Arten von Daten, abgeleitet von einer IRepository Schnittstelle, gemeint sind.

In Implementierungen spricht der Code mit einer Datenquelle, sei dies ein Verzeichnis von XML-Dateien oder eine Datenbank oder auch nur ein Cache. Ist es möglich, diese Implementierungen zuverlässig zu testen? Ich sehe keine Scheinimplementierung, weil ich dann nur den Scheincode und nicht den eigentlichen Code teste.

Answer 1

Nein, Sie würden einen Mock verwenden, wenn Sie eine Klasse schreiben, die eine IRepository verwendet. Für die Implementierungen von IRepository müssen Sie mit der entsprechenden Datenquelle testen. Für Datenbanken ist das ein bisschen mühsam - für ein Dateisystem etwas weniger.

Wenn Sie Ihre Implementierung in Bezug auf Streams oder Reader ausdrücken können, erleichtern Sie das Leben: Tests für diese Teile der Implementierung können gegen In-Memory-Datenquellen oder Streams von Ressourcen im Test gehen Versammlung. Natürlich werden Sie wahrscheinlich einige Tests benötigen, die zu einer echten Datenbank oder dem Dateisystem gehen, aber hoffentlich weniger.

Ob Sie solche Tests "Unit" -Tests nennen oder nicht, hängt davon ab, wie Sie Komponententests definieren. persönlich interessiere ich mich nicht allzu sehr um die Namen beteiligt, aber ich tun kümmern sich um Tests. Gerade bei Datenbanken kann dies etwas schmerzhaft sein (vor allem, wenn Sie parallel Tests durchführen wollen) - aber sie können meiner Erfahrung nach auch sehr wertvoll sein.

Answer 2

Ich denke, wenn Sie Code testen, der tatsächlich persistent ist oder Daten abfragt, möchten Sie wahrscheinlich tatsächlich eine Datenbank treffen.

Dies sind Integrationstests und keine Komponententests.

Sie könnten eine Testdatenbank einrichten, in der Sie den Status der Daten kennen und die Tests dagegen ausführen. Wahrscheinlich möchten Sie den Tests auch mitteilen, dass sie sich von Ihren Komponententests unterscheiden und nicht bei jedem Einchecken ausgeführt werden müssen (in nUnit können Sie Ihre Testklasse mit einem Attribut versehen, das anzeigt, dass sie nicht ausgeführt werden soll)

Answer 3

Allgemein Sprechen Sie nicht Einheit testen Sie jeden Code, dessen einziger Zweck ist, mit einer Datenquelle zu sprechen. Möglicherweise möchten Sie das Repository dennoch automatisch testen, aber ein solcher Test ist per Definition ein Integrationstest. Wahrscheinlich möchten Sie diese Tests nicht als Teil Ihres "First Pass" Builds ausführen, z. Einrichten der Datenbank und Aufräumen nach sich selbst kann eine nicht unerhebliche Zeit in Anspruch nehmen.

Wenn Ihr Repository andere Verantwortlichkeiten hat (z. B. die Implementierung des Arbeitseinheitsmusters), dann sollten Sie diese separat testen.

Answer 4

An einem bestimmten Punkt der Implementierung des IRepository verwenden Sie eine API eines Drittanbieters, die tatsächlich zu/von der Datenbank/file/xml liest/schreibt. Was Sie tun möchten, ist diese APIs zu verspotten, um sicherzustellen, dass Ihr Code die richtige API in der richtigen Reihenfolge aufruft.

Wenn Sie also aus der Datenbank lesen, können Sie SqlConnection und SqlCommand vortäuschen und sicherstellen, dass Sie die richtigen Methoden für diese Klassen aufrufen. Wenn Sie in einen Stream schreiben, können Sie sich den Stream vortäuschen und sicherstellen, dass Sie ihn z. B. löschen und entsorgen.