Testy jednostkowe handlera

Używam Mediatr. W kodzie mam handler, który spina kilka innych serwisów, które są już przetestowane. Pisanie testów integracyjnych dla każdej reguły, która już została sprawdzona na poziomie unit testów wydaje się głupim pomysłem. Pomijam już zupełnie dodawanie danych na potrzeby zapełnienia bazy testowej. No ale jak inaczej zweryfikować czy sam handler działa w poprawny sposób poprzez połączenie tych building blocków jakimi są serwisy.

Dodatkowo popełniłem błąd używając DbContext bezpośrednio w serwisach. Posiadając w handlerze serwisy które korzystają z DbContextu oraz te które korzystają z Dappera mam problem ze spięciem zależności w takim hanlerze żeby go przetestować jednostkowo. Serwisy w izolacji były testowane z użyciem InMemoryDb. Sam dapper opakowany jest w różne klasy w zależności od potrzebnych danych.
Myślałem o mocku wszystkich serwisów i sprawdzaniu wywołań metod, ale nie wiem czy to jest poprawne testowanie.

Co sądzicie o moim problemie. Czy jest sens ratowania tego czy czeka mnie większy refactor.

tymlua napisał(a):

Myślałem o mocku wszystkich serwisów i sprawdzaniu wywołań metod, ale nie wiem czy to jest poprawne testowanie.

No to jest zdecydowanie kontrproduktywne, bo nie wykryjesz w ten sposób żadnego błędu, namęczysz się z pisaniem testów, a za to utrudnisz ewentualną refaktoryzację.

Co sądzicie o moim problemie. Czy jest sens ratowania tego czy czeka mnie większy refactor.

Ok, ale co te serwisy robią i czemu handler ich używa?
Bo może powinieneś mieć tylko testy handlera, a nie serwisów.
Czy jest tam jakaś testowalna logika, czy tylko operacje na bazie? Bo jeśli tylko baza, to nie wiem, czy jest sens cokolwiek mockować, pewniej będzie pisać i czytać z bazy.

Co to za serwisy? Dziedzinowe? Aplikacyjne?

W moich projektach handlery z MediatR pełnią rolę serwisów aplikacyjnych, wołając i orkiestrując obiekty dziedziny w pewien proces biznesowy. Zwykle wołane są z jakiegoś API (głównie HTTP, ale różnie bywa), więc testuję ich zachowania integracyjnie robiąc testy API, zwykle bez mocków zamiast tego stosując test containers czy bazy danych in memory. Sporadycznie stosuję stuby i fake'i np. jeśli mój handler musi odpytać zewnętrzne API to piszę sobie fejkową implementację interfejsu do komunikacji z API w której zwracam wcześniej przygotowane dane, czasem zamiast tego stosuję wiremocka.

Natomiast obiekty dziedzinowe jeżeli mają jakąś logikę która warto przetestować to testuję je dodatkowo jednostkowo bo testy jednostkowe są szybsze w wykonaniu. Ponieważ obiekty dziedziny nie mają zależności do warstw wyższych (Clean/Onion/Hexagonal Architecture), to nie ma też potrzeby stosowania mocków, stubów czy fake'ów.