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.
- Rejestracja:prawie 11 lat
- Ostatnio:około 11 godzin
- Postów:1473
C# 
- Rejestracja:około 21 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Space: the final frontier
- Postów:26433
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? ;)
- Rejestracja:około 17 lat
- Ostatnio:około 12 godzin
- Lokalizacja:Wrocław
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.
- Rejestracja:około 6 lat
- Ostatnio:ponad 5 lat
- Postów:139
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.
@superdurszlak Uważam, że masz problem z architektura a nie testowaniem.ale czemu ja? :D