Hej! W moim zespole 3 programistów, gdzie jestem TL aktualnie rozwijamy aplikację w architekturze mikroserwisowej. Piszemy mikroserwisy w Springu, testujemy w Junit i Spring Cloud Contract. Od przyszłego miesiąca do naszego zespołu ma dołączyć jedna osoba odpowiedzialna za testy automatyczne, a ja mam tą osobę wdrożyć i pokierować co ma robić.
Ogólnie to myślę o stworzeniu dla nowego testera środowiska TEST, gdzie mógłby testować nasze aplikacje, ale dodatkowo mógłby napisać jakieś scenariusze testowe i porobić dla naszej aplikacji jakieś testy funkcjonalne dla API (nie było na to czasu). Gość ma pisać też testy w Javie, stąd pytanie czy jak mu każe zrobić osobny mikroserwis/repo w Spring Boocie do testów żeby sobie tam działał to będzie Ok? Jak u Was w zespołach wygląda praca takiego testera automatycznego? Jakie ma obowiązki?
Marcys32 napisał(a):
Ogólnie to myślę o stworzeniu dla nowego testera środowiska TEST, gdzie mógłby testować nasze aplikacje, ale dodatkowo mógłby napisać jakieś scenariusze testowe i porobić dla naszej aplikacji jakieś testy funkcjonalne dla API (nie było na to czasu). Gość ma pisać też testy w Javie, stąd pytanie czy jak mu każe zrobić osobny mikroserwis/repo w Spring Boocie do testów żeby sobie tam działał to będzie Ok? Jak u Was w zespołach wygląda praca takiego testera automatycznego? Jakie ma obowiązki?
W jakim celu miałby tworzyć nowy mikroserwis w kontekście tworzenia testów automatycznych / funckcjonalnych API?
Jeśli będzie testował API to pewnie w jakimś Karate, RestAssured + Cucumber, ewentualnie w czymś podobnym.
superdurszlak napisał(a):
Marcys32 napisał(a):
Ogólnie to myślę o stworzeniu dla nowego testera środowiska TEST, gdzie mógłby testować nasze aplikacje, ale dodatkowo mógłby napisać jakieś scenariusze testowe i porobić dla naszej aplikacji jakieś testy funkcjonalne dla API (nie było na to czasu). Gość ma pisać też testy w Javie, stąd pytanie czy jak mu każe zrobić osobny mikroserwis/repo w Spring Boocie do testów żeby sobie tam działał to będzie Ok? Jak u Was w zespołach wygląda praca takiego testera automatycznego? Jakie ma obowiązki?
W jakim celu miałby tworzyć nowy mikroserwis w kontekście tworzenia testów automatycznych / funckcjonalnych API?
Napisania własnego mikroserwisu w którym byłyby testy np. w rest-assured, miałby swoje repozytorium, w przyszłości będą także inni testerzy bo projekt się będzie rozrastać. Widziałem też takie projekty. To po prostu taka dywagacja :D
Marcys32 napisał(a):
Napisania własnego mikroserwisu w którym byłyby testy np. w rest-assured, miałby swoje repozytorium, w przyszłości będą także inni testerzy bo projekt się będzie rozrastać. Widziałem też takie projekty. To po prostu taka dywagacja :D
Chyba potrzebuję wyjaśnienia - chcesz, aby zacząć testowanie API i testy automatyczne na nowo powstającym mikroserwisie (i który i tak by powstał), a dla istniejących dopiero później?
Jeśli tak no to w zasadzie jest spoko, kwestia priorytetów i tego, co uznacie w zespole za najważniejsze i do otestowania w pierwszej kolejności. My na razie nie mamy w zespole testera automatycznego (choć możliwe, że po prostu zaangażujemy się jako zespół i tyle), ale testy automagiczne / API też mają wejść. Generalnie zamiast tworzyć pet projecty żeby na nich się bawić w testowanie, to jako PoC wziąć jakiś scenariusz / feature (jak to tam zwał, Cucumber ma chyba w nomenklaturze podział na ficzery) który i tak byłby do otestowania. Co najwyżej można puszczać te testy w CI jakoś luzem (wyłączyć zależności, statusy, failowanie buildów), żeby nie psuły pipeline'ów dopóki eksperymentujesz, i puszczać je jakiś czas testowo. A jak będzie miało ręce i nogi, można pomyśleć o zintegrowaniu z CI już do końca.
Napisania własnego mikroserwisu w którym byłyby testy np. w rest-assured, miałby swoje repozytorium, w przyszłości będą także inni testerzy bo projekt się będzie rozrastać. Widziałem też takie projekty. To po prostu taka dywagacja :D
Czemu ma mieć osobne repo? Nie chcecie mieć kontroli nad tym, co wrzuca?
Jeśli będzie testował API to pewnie w jakimś (...) Cucumber, ewentualnie w czymś podobnym.
Ogór to taki syf, że lepiej nie, ma piękne założenia ale w praktyce później żaden "byznes" nie czyta i jest osobna, zbędna warstwa do utrzymywania
Jak u Was w zespołach wygląda praca takiego testera automatycznego? Jakie ma obowiązki?
Czasami jest osobne środowisko, czasami na jakiś request wstaje wszystko na dockerach i trzeba dopisać przed testami porządny setup. Plus skoro macie mikroserwisy to możecie je testować zarówno razem, jak i w izolacji.
null null napisał(a):
Ogór to taki syf, że lepiej nie, ma piękne założenia ale w praktyce później żaden "byznes" nie czyta i jest osobna, zbędna warstwa do utrzymywania
Z drugiej strony IMO mniejszym złem jest ogór, niż kolejny in-house framework do robienia API testów / testów automatycznych, albo in-house framework do wrapowania tychże testów w ogórkopodobny interfejs. Albo obydwa ;)
Tak, ogólnie idea jest taka aby sobie zrobił osobny mikroserwis np. w Spring Boocie z testami, np Cucumber i robił testy np. funkcjonale naszych mikroserwisów poprzez np Rest-assured. Przy okazji tworząc scenariusze testowe, dokumentując naszą pracę, projekt. Co o tym myślicie? To moje pierwsze poważniejsze decyzje odnośnie testowania, do tej pory tylko zajmowałem się programowaniem i podziałem zadań etc.
IMO dedykowany mikroserwis do odpalania testów na innych mikroserwisach brzmi bardzo dziwnie. Dlaczego ma istnieć jako dedykowany mikroserwis? Gdzie ten mikroserwis będzie żył? Będzie wdrażany razem z innymi mikroserwisami? Kto i jak będzie go uruchamiał? Jak testy realizowane przez mikroserwis będą integrowane z CI?
Szczerze mówiąc brzmi to dla mnie jak mocny przerost formy nad treścią. No chyba, że cały czas mówimy nie o autentycznym mikroserwisie tylko np. osobnym repozytorium lub module w repozytoriach... no ok, wasz wybór gdzie te testy będą żyły. Tak czy owak widziałbym je raczej jako część CI, niż jakiś mikroserwis który żyje sobie gdzieś i nie bardzo wiadomo czemu ani po co ;)
superdurszlak napisał(a):
IMO dedykowany mikroserwis do odpalania testów na innych mikroserwisach brzmi bardzo dziwnie.
Tzn nie to miałem na myśli, miałem na myśli osobny mikroserwis gdzie tester automatyczny pisałby testy np. funkcjonalne w rest-assured
Marcys32 napisał(a):
superdurszlak napisał(a):
IMO dedykowany mikroserwis do odpalania testów na innych mikroserwisach brzmi bardzo dziwnie.
Tzn nie to miałem na myśli, miałem na myśli osobny mikroserwis gdzie tester automatyczny pisałby testy np. funkcjonalne w rest-assured
Zamień słowo mikroserwice, słowem projekt. Mikroserwice to projekt który wystawia jakieś rest/soap api. A ty nie chcesz wystawiać api tylko testy z javy odpalać.
BTW lepszym rozwiązaniem jest jak testerzy mają osobny podprojekt z testami integracyjnymi. Da się to ogarnąć w mavenie. Wtedy programiści mogą robić review takim testom. Da się też wtedy ogarnąć żeby takie testy były uruchamiane automatycznie po zbudowaniu mikroserwisu. Czyli etapy w mavenie to:
- Kompilacja
- Uruchomienie - testów jednostkowych
- Zbudowanie jara
- Uruchomienie Jara
- Uruchomienie baz w Dockerach
- Uruchomienie testów integracyjnych
- Posprzątanie wszystkiego
@Marcys32: Nie wiem czy rozumiemy to samo pod pojęciem mikroserwis - mówisz tak jakbyś miał na myśli repozytoria Git, a nie mikroserwisy / joby / serwery CI / aplikacje etc.
Zmierzam do tego, że celem istnienia takich testów jest bycie częścią procesu CI, jako jeden z etapów weryfikacji, a nie bycie kolejną usługą w architekturze mikroserwisów. Same w sobie nie stanowią usługi, nie są długo żyjącym procesem który stanowi część biznesową (uS pokrywający konkretny biznesowy use case) ani infrastrukturalną / service mesh itd (nie są np. load balancerem który umożliwia funkcjonowanie całości). Z tego względu kompletnie nie rozumiem pomysłu umieszczania ich w mikroserwisie.
Co do tego, czy powinny żyć w dedykowanym repozytorium / projekcie czy w modułach poszczególnych repozytoriów dla poszczególnych mikroserwisów - to już jak Wam bardziej pasuje. Mając je blisko mikroserwisów (w ich repozytoriach) będziecie mieć jako zespół większą kontrolę nad tym, co się z nimi dzieje, nie będzie tak że mikroserwis żyje swoim życiem, a jego testy automatyczne swoim.
Z drugiej strony pewnie możecie mieć kiedyś zagwozdkę, gdzie ma żyć np. bardziej rozbudowany przypadek testowy, który nie testuje pojedynczego mikroserwisu, a bardziej na zasadzie e2e np. po dokonaniu zakupów i sfinalizowaniu płatności zamówienie wyląduje w historii zamówień. Coś w ten deseń.
Co do testów automatycznych (tu rozumiem takie testy bardziej od strony UI np. TestCafe, Selenium) to też pojawia się pytanie, jak to wszystko wygląda od strony UI - czy stosujecie np. architekturę mikrofrontendów i rozwijacie je odrębnie, każdy może być oddzielnie i mieć swoje testy, czy też np. jest jedna aplikacja frontendowa, mobilna itd. uderzająca do uS, ew. odseparowana przez API gateway którego używa... widzisz, to zależy ;)