Jak testować mikroserwisy

Cześć.

W ramach nauki jestem w trakci pisania prostego projektu opartego na mikroserwisach. Potrzebuję pomocy w kontekście testowania, byłbym wdzięczny jeśli ktoś by opwiedział po krótce jak zabrać sie do tego tematu.

Pytanie jest proste, jak powinno się testować mikroserwisy jako całość (i czy powinno się je tak testować). Załóżmy że mamy dwa mikroserwisy, jeden z ogolnym zalozeniem autoryzacji i autentykacji Identity, drugi powiedzmy Employees który związany bedzie z pracownikami (zatrudnianie,zwalnianie etc.). Teraz osoba z odpowiednia rola dodaje pracownika do Employees. Dodany pracownik po krótkim czasie (jakimś tam rabbitmq obrabia sobie wiadomości w tle) bedzie mógł zalogować sie do systemu (strzeli sobie POST do Identity,który zwróci sobie json tokena). Analogicznie gdy zostanie zwolniony możliwość ta zostanie mu odebrana w wyniku czego dostanie 401 i bedzie musiał szukać roboty w innym miejscu.

Teraz czy takie casy powinny byc testowane w obrębie danego mikroserwisu, czyli Identity wysyła do siebie wiadomość typu EmployeeFiredMessage i działa sobie w swoim zakresie,sprawdza jakies reguły i na końcu blokuje takiego użytkownika co w gruncie rzeczy sprowadza sie do napisania jakiegoś tam integracyjnego testu,który bedzie sprawdzał to co właśnie napisałem... A może powinienem stawiać wszystkie serwisy na baczność, odpytywać je po kolei a następnie odczytwać jakie dostaje odpowiedzi.Tylko jak taki proces zautomatyzować ? Ma to sens jak mam dwa,trzy mikroserwisy i moge to po ludzku sprawdzić w innym przypadku odpada.

Byłbym wdzięczny za jakieś naprowadzenie na właściwy tor :)

Powinieneś mieć dwa rodzaje testów. Jeden, który testuje serwis w izolacji od reszty serwisów: są one bardzo pomocne w czasie developmentu oraz pozwalają na przetestowanie takich przypadków, których nie ma np. serwis B zwraca błędy; może teraz tego nie robi, ale mikroserwisy rozwijają się niezależnie, więc trzeba być przygotowanym na wszystko. Oczywiście potrzebujesz też testów testujących wszystko na raz, bo tylko wtedy sprawdzisz, czy połączenia pomiędzy serwisami działają tak jak należy.

Czy to dużo pracy? Taka jest cena elastyczności, które wprowadzają mikroserwisy

Zapraszam: https://github.com/Pharisaeus/almost-s3

@slsy: Ok czyli testy integracyjne w ramach pojedynczego mikroserwisu które w gruncie rzeczy bedą testować publiczne api danego serwisu.
Natomiast czy w przypadku testów całościowych dobrym podejściem byłoby użycie czegoś takiego jak nuke w zamyśle że stawiam swoje mikroserwisy (wraz z cala infrastruktura) w dockerze za pomoca tego narzedzia a następnie tworze osobny projekt dedykowany testom gdzie za pomoca jakies abstrakcji nad clientem http strzelam w api wystawiane przez te serwisy ?

@Shalom: Dzieki za linka. Czy znasz moze jakiś .netowy odpowiednik ?

Odpowiednik czego konkretnie? Bo w tamtym projekcie nie ma zadnych magicznych rozwiązań które wymagałby specjalnego wsparcia jakiegoś frameworka. Jestem pewien że jest zarówno wiremock jak i in-memory db dla .netu

@allonder1992: w idealnym świecie powinieneś mieć środowiska testowe wyglądające identycznie w 100% jak produkcja. Jeśli coś zmienisz (nawet konfigurację) to znaczy, że jest jakiś obszar, który nie jest przetestowany. Np. teraz w projekcie mam wszystko postawione w AWS ECS i jestem strasznie wkurzony, bo ciężko postawić tą usługę lokalnie w porównaniu np. do kubernetesa, więc lokalne testy całego projektu totalnie nie wykrywają błędów wynikających z błędnej konfiguracji ECSa i infrastruktury. Oczywiście nigdy nie przetestujesz projektu w 100%, więc zawsze trzeba polegać na instynkcie i wybierać mniejsze zło tak, żeby się nie narobić a mieć jakiś akceptowalny poziom wytestowania systemu. Idealną metodą wydaje się być testowanie na produkcji ale do tego trzeba ogromnego doświadczenia i ogromnych nakładów związanych z automatyzacją i projektowaniem systemu na co mogą pozwolić sobie tylko najwięksi gracze

@slsy: jak masz dobrze zrobione mikroserwisy, to nie jestes w stanie przetestowac produkcyjnego „snapshotu”, poniewaz z definicji masz niezalezne deploymenty (przy duzej skali mozesz miec deployment nawet co 5 minut). Wyjatkiem jest jakis release train, kiedy wstrzykujesz release na prod, aby przetestowac caly wagon - ma to jednak negatywne konsekwencje dla szybkosci wdrazania nowych ficzerow, impakt na organizacje pracy itp

Wracajac do pytania:

1. „monitoring is new testing”
2. Testujesz na produkcji - ficzer flagi, canary deployment, A/B testy itd. Nie, nie trzeba miec duzego doswiadczenia - trzeba miec narzedzia.
3. Testy integracyjne w ramach mikroserwisu
4. Jakies cyklicznie odpalane behaty, niezaleznie od releasow (czyli mozesz wykryc blad post factum)
5. Inne automaty klikajace UI, robiace requesty do kilku uslug w ramach kontekstu, ktory kontroluje zespol