[romcat]

Programiści 15k, jak się powinno testować warstwy controller-service-repo? Jak testuje controller to powinienem mockować service, następnie w service mockować repo? Czy ktoś mógłby przejrzyście to rozpisać, bo niestety w internecie na każdej stronie jest inaczej ( ͡° ͜ʖ ͡°)
#programowanie #programista15k #informatyka

[elf_pszeniczny]

@romcat: zależy od rodzaju testu - jednostkowy, integracyjny

[romcat]

@elf_pszeniczny: A mógłbyś to rozpisać jak powinno być prawidłowo, zgodnie ze sztuką?

[B.....n]

@romcat: Jeśli na każdej stronie jest inaczej to znaczy że mogą być różne podejścia. U mnie w robocie przyjęło się że głównie testuje się warstwę serwisową ze względu że tam jest najwięcej logiki i jak się coś psuje to raczej na pewno w tej warstwie się psuje. Przy testach serwisów mockujesz sobie dane z repo. Jak chcesz sobie testować controllery to możesz mockować sobie serwisy i testujesz sobie walidatory danych wejściowych

[GotoFinal]

@romcat: w jednostkowych/unitowych mockujesz to czego nie testujesz, ot cała logika. Więc jak testujesz czy poprawnie mapujesz dane z bazy do reprezentacji domenowej to mockujesz bazę. Jak testujesz czy logika kontrollera poprawnie zwróci bład jak brakuje czegoś w requescie, to mockujesz serwisy do których się komunikuje.

A w integracyjnych to najlepiej imho testować po całości, tak by wysyłać wszystkie requesty przez całą warsrwe siecową i tylko dajesz bazę w pamięci lub

[B.....n]

@romcat: Musisz też rozróżnić testy jednostkowe i integracyjne. Nawet jeśli tetsty jednostkowe nie pokażą błędów to testy integracyjne mogą wyłapać błąd

[diabel_z_piekla]

@romcat: W testach jednostkowych testujesz zazwyczaj jedną warstwę i odcinasz się od warstwy zależnej przy użyciu mocka (czyli pisząc unit test controllera mockujesz service i sprawdzasz czy dobrze mapujesz input controllera na input service, czy dobrze mapujesz błędy itp itd.)

Dodatkowo warto mieć testy integracyjne co testują cały flow: controller -> service -> db, gdzie nic nie mockujesz tylko stawiasz cały system i bazę w pamięci/kontenerze.

[romcat]

@diabel_z_piekla: To jak powinien wygladać prawidłowy test integracyjny? Wysyłam sobie spreparowanego requesta do controllera, sprawdzam sobie mapowanie, sprawdzam czy serwisowa metoda jest wywoływana, tak samo w repo a na samym końcu wyciągam z bazy dane i sprawdzam czy są prawidłowe?

[romcat]

@GotoFinal: A w którym miejscu powinna być logika, czyli obługa naszego requesta, rzucanie wyjatków itp. Bo widzę też tu jakieś dwie szkoły, jedni to robią w controller i w service tylko odpytka do repa, a znów inni jak najmniej w controller a cała obsługa błedów i logiki w service. Jakie podejście jest najlepsze, albo najbardziej uznane?

[GotoFinal]

@romcat:

Bo widzę też tu jakieś dwie szkoły, jedni to robią w controller i w service tylko odpytka do repa

No też zależy... imho jedyna logika w kontrollerza to ta potrzebna by dane nadawały się do serwisu, więc czasem wyląduje tam trochę prostej logiki lub walidacji. Jak np obiekt do serwisu musisz poskładać ręcznie z danych z requestu i url/ciastek/cokolwiek. Ale tak to żadnej logiki biznesowej tam nie ma.

No i

[B.....n]

@romcat: Test integracyjny działa na żywych danych w bazie, które są odtwarzane co każde wywołanie testu integracyjnego. W teście integracyjnym nie ma mocków. Testy integracyjne mogą być przeprowadzane przez zewnętrzne narzędzia. Testy jednostkowe są przeprowadzane wewnątrz tworzonej aplikacji, bez bazy, z mockami i za pomocą wewnętrznej biblioteki w aplikacji. Testy integracyjne mogą przeprowadzać takie akcje jak rejestracja użytkownika, logowanie w jednym długim ciągu tak jakby to robił użytkownik z kilkoma wyjątkami

[diabel_z_piekla]

@romcat: Jak masz test integracyjny to traktujesz system jak black-box. Wysyłasz request i sprawdzasz otrzymany response, to co się dzieje po drodze w środku systemu Cię nie interesuje, bo to powinieneś mieć dokładnie pokryte w testach unitowych. Idealnie nie powinieneś w teście w ogóle bezpośrednio sprawdzać stanu bazy, jak masz typowego CRUDA to wrzucasz POSTa, weryfikujesz response i później przy użyciu GET sprawdzasz czy jest to co powinno być. Jak nie

[Saly]

@romcat: najlepiej testować w taki sposób jak aplikacja będzie używana na produkcji. Jak apka używa bazy to testuj z bazą. Jak apka wystawia http API to testuj to API. Takie testy to must have, testy na niższym poziomie (np. unity) to tylko dodatek, który można wyrzucić (i często się tak robi, bo refaktor). Unity mają sens jak przetestowanie czegoś na ich poziomie ma sens np. bo testy na wyższym poziomie są

[villager]

@romcat: spróbuj o tym pomyśleć bardziej w kategorii BDD niż samego mockowania repozytoriów, może trochę cię to zainspiruje bo nie wiem do końca jak słowami opisać jak się to powinno robić

[romcat]

https://thankgodukachukwu.medium.com/unit-and-integrated-testing-spring-boot-and-junit-5-99b9745b782a

Powyżej jest link do przykładowego testu jednostkowego i integracyjnego, jeśli chodzi o jednostkowy to spoko, ale w teście integracyjnym ten ktoś też Mockuje swój service i podaje co on ma zwrócić, to dla mnie kompletnie bez sensu. Może ktoś z Was na to zerknąć i być może wyjaśnić?

[Saly]

@romcat: cała nomenklatura testów jest troche bez sensu, bo tak naprawdę co to zmienia? Testy to testy, cała różnica to poziom na którym testujesz (czy na poziomie kodu czy np. na poziomie API), cechy (wolne, szybkie, ile środowiska trzeba przygotować) i jak dużo kodu (cudzego bądź nie) chcesz dotknąć. Idąc w ekstrema: testowanie modułu mającego milion lini kodu robimy na poziomie aplikacji (czyli wołamy metody): czy taki test to unit test?