Witajcie. Piszę sobie api. Korzystam z mediatR. Czyli handlery itp. No i powiedzmy, że mam opcje tworzenia użytkownika. Czyli mam Command z danymi usera, następnie przed uruchomieniem handlera jest robiona walidacja command (FluentValidation: ilość znaków, email itp). Jeśli walidacja przejdzie to command trafia do handlera. Do handlera wstrzykuje CreateUserService z metodą generyczną (bo mam różne typy obiektu user) i powiedzmy SendEmailService. No i jak tworzę sobię obiekt Usera to już nie sprawdzam poprawności danych (było sprawdzone wcześniej). No i teraz testy. Czy powinienem założyć w testach, że do np CreateServiceUser trafią poprawne dane i tak to testować? Poprawne mam namyśli odpowiednie znaki, prawidłowy email. Czyli te rzeczy, które np UserManager nie wychwyci.
Zrobiłem sobie testy klasy CreateUserService. I np przekazuje w userze email taki: "Test1 @Test.pl". Czyli generelanie nie poprawny format bo jest spacja. Ale UserManager mi to przepuszcza w testach (Nie robię, żadnch mocków, działa na EF in Memory). Ale jakbym takie coś testował na żywym api to nie przejdzie. Czyli wywali się już na fluentvalidation.
Zależy który kawałek chcesz przetestować. Jeśli w teście sprawdzasz tylko to co się dzieje już po walidacji, to dane powinny być poprawne (bo przecież nie sprawdzasz tu walidacji, tylko dalszą logikę)
To raczej odwieczny problem z tym gdzie i jak robić walidację. I jeśli zdecydujemy się robić walidację w warstwie widoku (api), to czy powinniśmy powielać te same reguły w warstwach niżej (serwisy domenowe).
Trochę dziwne pytanie. Przecież testujesz swój kod który masz napisany! Co najwyżej mógłbyś się zastanawiać czy w takim razie przeprowadzasz walidacje w dobrym miejscu, albo czy piszesz test na odpowiednim poziomie abstrakcji.
Może obok tych unit testów powinny być też testy integracyjne/e2e, które faktycznie stawiają tą aplikacje i puszczają requesty HTTP i walidują czy wszystko działa tak jak powinno? ;)
szydlak napisał(a):
Czy powinienem założyć w testach, że do np CreateServiceUser trafią poprawne dane i tak to testować? Poprawne mam namyśli odpowiednie znaki, prawidłowy email.
Skoro taką masz architekturę, i tak to będzie działało przy faktycznym korzystaniu z aplikacji, to owszem.
Zrobiłem sobie testy klasy CreateUserService. I np przekazuje w userze email taki: "Test1 @Test.pl". Czyli generelanie nie poprawny format bo jest spacja. Ale UserManager mi to przepuszcza w testach
No i dobrze. Zadaniem tego serwisu jest jak rozumiem wstawienie do bazy i wysłanie maila, a nie walidacja.
neves napisał(a):
To raczej odwieczny problem z tym gdzie i jak robić walidację. I jeśli zdecydujemy się robić walidację w warstwie widoku (api), to czy powinniśmy powielać te same reguły w warstwach niżej (serwisy domenowe).
Jeśli w module numer 1 dwie klasy, które posiadają inne efekty uboczne, implementują ten samy interfejs. To skąd osobą, która chce się komunikować z tym modułem ma się dowiedzieć o konsekwencjach związanymi z tymi efektami ubocznymi. Z walidacji w kliencie.?
@szydlak Uważam, że masz problem z architektura a nie testowaniem.
Shalom napisał(a):
Trochę dziwne pytanie. Przecież testujesz swój kod który masz napisany! Co najwyżej mógłbyś się zastanawiać czy w takim razie przeprowadzasz walidacje w dobrym miejscu, albo czy piszesz test na odpowiednim poziomie abstrakcji.
Może obok tych unit testów powinny być też testy integracyjne/e2e, które faktycznie stawiają tą aplikacje i puszczają requesty HTTP i walidują czy wszystko działa tak jak powinno? ;)
Jeśli spójności transakcyjnej obiektu domenowego pilnuje walidacja poziomu wyżej, to znaczy, że ma przełamaną hermetyzację. A nie że przeprowadza walidację w złym miejscu.