Technisch gesehen sind Tests, die mit einer Datenbank (nosql oder anderweitig) kommunizieren, keine Komponententests, da die Tests Interaktionen mit einem externen System testen und nicht nur eine isolierte Codeeinheit testen. Tests, die mit einer Datenbank kommunizieren, sind jedoch oft äußerst nützlich und häufig schnell genug, um mit den anderen Komponententests ausgeführt zu werden.
Normalerweise habe ich eine Service-Schnittstelle (z. B. UserService), die die gesamte Logik für den Umgang mit der Datenbank kapselt. Code, der sich auf UserService stützt, kann eine simulierte Version von UserService verwenden und ist leicht zu testen.
Beim Testen der Implementierung des Dienstes, der mit Mongo kommuniziert (z. B. MongoUserService), ist es am einfachsten, Java-Code zu schreiben, der einen Mongo-Prozess auf dem lokalen Computer startet/stoppt, und Ihren MongoUserService damit verbinden zu lassen, siehe diese Frage für einige Anmerkungen.
Sie könnten versuchen, die Funktionalität der Datenbank zu verspotten, während Sie MongoUserService testen, aber im Allgemeinen ist das zu fehleranfällig und testet nicht, was Sie wirklich testen möchten, nämlich die Interaktion mit einer echten Datenbank. Wenn Sie also Tests für MongoUserService schreiben, richten Sie für jeden Test einen Datenbankstatus ein. Sehen Sie sich DbUnit für ein Beispiel eines Frameworks an, um dies mit einer Datenbank zu tun.
