Technicznie testy, które komunikują się z bazą danych (nosql lub inną) nie są testami jednostkowymi, ponieważ testy testują interakcje z systemem zewnętrznym, a nie tylko testują wyizolowaną jednostkę kodu. Jednak testy, które komunikują się z bazą danych, są często niezwykle przydatne i często są wystarczająco szybkie, aby można je było uruchomić z innymi testami jednostkowymi.
Zwykle mam interfejs usługi (np. UserService), który zawiera całą logikę obsługi bazy danych. Kod, który opiera się na UserService, może używać fałszywej wersji UserService i można go łatwo przetestować.
Podczas testowania implementacji usługi, która komunikuje się z Mongo (np. MongoUserService), najłatwiej jest napisać kod java, który uruchomi/zatrzyma proces mongo na lokalnym komputerze i połączy się z nim MongoUserService, zobacz to pytanie dla niektórych notatki.
Możesz próbować zakpić funkcjonalność bazy danych podczas testowania MongoUserService, ale generalnie jest to zbyt podatne na błędy i nie testuje tego, co naprawdę chcesz przetestować, czyli interakcję z prawdziwą bazą danych. Dlatego podczas pisania testów dla MongoUserService ustawiasz stan bazy danych dla każdego testu. Spójrz na DbUnit, aby zapoznać się z przykładem frameworka do robienia tego z bazą danych.
