Was sollte ich bei Tests einer Anwendung mit Service- und DAO-Schicht verspotten?

Meine Klassen folgen dieser Struktur

• Service Tier (erstellt und ordnet InputDTO DB-Daten zu)
• DAO Tier (führt tatsächlich DB-Aufrufe aus)

Wenn ich JUnit-Tests der Service-Schicht schreibe, wird die DAO-Schicht aufgerufen. Dies erwartet eine tatsächliche DB-Verbindung und das Abrufen von Daten aus der DB.

Sollte ich die DAO-Schicht vollständig von der Service-Schicht verspotten oder sollte ich die DB-Verbindung und die von der DB empfangenen Daten verspotten?

Zweitens erwartet die App bestimmte Daten aus einem Cache.

Für die JUnit-Laufzeit gibt es keinen Cache. Wie soll damit umgegangen werden? Die Service-Tier-Methode umfasst das Nachschlagen des Caches, um die Details abzurufen.

Ich werde über Test-Doppel sprechen. Wenn Sie diesen Begriff nicht kennengelernt haben, möchten Sie wahrscheinlich zuerst den Artikel- Link von Martin Fowler lesen .

• Für den Datenbanktest - Wenn Sie einen reinen Unit-Test-Ansatz verfolgen, würden Sie einen Stub- oder einen Mock- Test Double-Typ verwenden, um die DB-Verbindung und ihre Antworten zu verspotten. Wenn Sie einen Mock verwenden, würde ich die Verwendung von Mockito, JMock oder Ihrem anderen bevorzugten Verspottungswerkzeug empfehlen. Dies ist jedoch ziemlich mühsam, wenn es darum geht, eine große Ressource eines Drittanbieters wie eine Datenbank zu testen.

• Für den Datenbanktest - Wenn Sie eine etwas lockerere Definition des Komponententests befolgen, können Sie ein Fake Test Double verwenden. In Ihrem speziellen Fall wäre dies eine In-Memory-Datenbank wie HSQL. Dies ist eine sehr beliebte Methode zum Testen Ihrer Datenbankschicht. Einige werden argumentieren, dass dies kein Unit-Test ist und dass es sich stattdessen um Integrationstests handelt. Ich denke, das ist eigentlich in Ordnung - Tatsache ist, dass Sie einige Tests haben, die Ihren Code herausschneiden :-)

• Für den Cache-Test - Ein Stub- Stil von Test Double ist hier wahrscheinlich Ihr Freund - abhängig davon, wie komplex die Cache-API ist.

HTH!

In der Zusammenfassung ist die Antwort recht einfach.

Sie haben drei Schichten.

[Der Testfall] -> [Das zu testende Verhalten] -> [Die von diesem Verhalten verwendeten Mitarbeiter]

Die dritte Schicht sollte verspottet werden. Zum Beispiel:

1. die PokemonCaptureServiceTest;
2. Tests PokemonCaptureService;
3. welche verwendet Pokeball

In diesem Beispiel stellt sich heraus, dass es sich um eine PokeballLogik von Drittanbietern handelt. Es erfordert alle Arten von Installationen wie Datenbankverbindungen und Eigenschaftendateien usw. Sie vertrauen darauf, dass Ihr Dritter es ordnungsgemäß getestet hat, und möchten es daher bei Ihren Tests von weglassen PokemonCaptureService. Daher sollte es verspottet werden.

Zu einem anderen Zeitpunkt und an einem anderen Ort ist der Mitarbeiter Pokeballjedoch eine einfache Klasse, die nur sehr wenig Komplexität in den Testfall einführt und problemlos in den Test aufgenommen werden kann. In diesem Fall können Sie entscheiden, eine reale Instanz von Pokeballin die PokemonCaptureServicezu testende Instanz aufzunehmen.

Es gibt keine feste Regel. Es liegt an Ihnen, Ihre Tests so zu gestalten, wie es Ihnen am besten erscheint. Ihr Ziel ist es, so schnell wie möglich korrekte und wartbare Tests zu erstellen. Erfahrung ist hier der Schlüssel. Schreiben Sie weitere Tests und Sie werden sehr bald eine gute Intuition dafür bekommen.

Es ist schwer zu sagen, was genau Sie testen möchten, denn nach der Frage zu urteilen, sind Sie überall. Daher ist es schwierig, Ihnen ein praktisches Beispiel für das weitere Vorgehen zu geben, als Sie zu Artikeln über das Verspotten von Dingen zu führen. Sie müssen also genauer sein und die Dinge ein wenig aufteilen:

• Möchten Sie testen, ob der Cache ordnungsgemäß funktioniert?

• Möchten Sie insbesondere einen DB-Aufruf testen?

• Möchten Sie die App testen, damit sie den Cache korrekt verwendet?

Sobald Sie genau entschieden haben, welche Einheit Sie testen möchten, wird die Auswahl der zu verspottenden Einheit einfach: Bei einem reinen Einheitentest sollte alles außer der "zu testenden Einheit" verspottet werden. Der Grund dafür ist, dass Sie anhand Ihrer Erwartungen an die Verspottungen sicher sein können, dass das getestete Gerät ordnungsgemäß funktioniert.

Abgesehen davon möchten Sie möglicherweise einige Tests in JUnit schreiben, die Integrationstests sind, dh weniger Mocks verwenden. Selbst wenn sie als Sanity Checks verwendet werden, um festzustellen, ob das Software-Design korrekt ist, sollten Sie sich darüber im Klaren sein, dass sie spröde sind und nicht immer einen Hinweis darauf geben, was genau mit Ihrer App oder Ihrem System nicht stimmt.