Projekt Vue3, jakie testy rozwijać jako junior z wolną ręką?

Dołączyłem do działu it jako junior QA 6msc temu, obecnie team się nie wyrabia więc 3 na 5 dni nie mam czego testować manualnie. Tech lead 10-osobowego zespołu dev ludzi z doświadczeniem max 3lata zaproponował, abym zaczął pisać testy (bo ogarniam kodowanie, ale w innym języku).

Wszystko super jednak czuję, że coś jest nie tak, ponieważ bardzo mi zależało na pisaniu testów automatyzujących Cypress / Playwright, jednak tech lead jest bardzo przeciwny, bo nie widzi senesu w testach, które "naśladują pracę usera, który klika sobie w guziki".

Proszę o poradę, ponieważ nie czuję, że rozwijam się w dobrym kierunku. Potrafię kodować Java + Spring, jednak wiem, że w przyszłości tego nie chcę robić.. Lubię kod, ale głównie to testowanie sprawia mi frajdę dlatego chciałbym automatyzować testy.

1. Czy powinien zamknąć jakoś ten wątek, przedstawić jakieś argumenty?
2. Odpuścić i czytać wypociny developerów w postaci komponentów vue na 1500lini kodu każdy, wchodzić głębiej w inne skrypty importowane po to, żeby pisać testy za pomocą Vitest, Vue Test Utils? A w przyszłości nie sądzę żebym musiał tym się zajmować w innej firmie.
3. Obecnie, jakie framework wybrać do testów główej apki na vue3, node 18.x?

PS. Nikt tam nie pisze testów, muszę sam wszystko wybrać i skonfigurować, teraz pipeline github action ogarnąłem.
Pozdrawiam!

qwerp12 napisał(a):

Wszystko super jednak czuję, że coś jest nie tak, ponieważ bardzo mi zależało na pisaniu testów automatyzujących Cypress / Playwright, jednak tech lead jest bardzo przeciwny, bo nie widzi senesu w testach, które "naśladują pracę usera, który klika sobie w guziki".

Ma rację, bo testy które "klikają w guziki" dotykają UI, a takie testy z natury są słabe i nierzetelne.

qwerp12 napisał(a):

1. Odpuścić i czytać wypociny developerów w postaci komponentów vue na 1500lini kodu każdy, wchodzić głębiej w inne skrypty importowane po to, żeby pisać testy za pomocą Vitest, Vue Test Utils? A w przyszłości nie sądzę żebym musiał tym się zajmować w innej firmie.

To z kolei jest skrajność w drugą stronę, pisanie testów pod szczegóły implementacyjne.

qwerp12 napisał(a):

1. Obecnie, jakie framework wybrać do testów główej apki na vue3, node 18.x?

Narzędzie nie ma znaczenia - znaczenie ma jak dobre testy napiszesz.

qwerp12 napisał(a):

PS. Nikt tam nie pisze testów, muszę sam wszystko wybrać i skonfigurować, teraz pipeline github action ogarnąłem.

To nie jest dobre. Testy które napiszesz będą działać, do momentu w którym jakiś programista doda zmianę która ma bug, i on go zepsuje. W zdrowym zespole to on powinien być odpowiedzialny za jego poprawę, nie Ty. Więc tak czy tak, jeśli to ma być zdrowy projekt, będziesz musiał pracować z programistami bardzo blisko. Na tyle blisko żeby zepsuty test dało się naprawić w minuty.

Ja poleciłbym Ci zaczęcie od czegoś takiego: https://github.com/symonk/Writing-Good-Gherkin-Syntax

nie widzi senesu w testach, które "naśladują pracę usera, który klika sobie w guziki".

W jakich testach widzi sens?

Riddle napisał(a):

qwerp12 napisał(a):

Wszystko super jednak czuję, że coś jest nie tak, ponieważ bardzo mi zależało na pisaniu testów automatyzujących Cypress / Playwright, jednak tech lead jest bardzo przeciwny, bo nie widzi senesu w testach, które "naśladują pracę usera, który klika sobie w guziki".

Moim zdaniem developerzy powinni enkapsulować logikę tak, żeby dało się do nich pisać testy unitowe, które pisze się łatwo i przyjemnie. Problem jest w tym, że w tego typu apkach webowych ludzie czasem wrzucają tę logikę luzem do komponentów. I to jest problem. Bo jak logika jest w komponencie, to zaczynasz testować całe komponenty, a nie funkcje, klasy...

GUI się ciągle zmienia oraz trudno je przetestować z automatu w sensowny sposób, więc ja bym dużo się nie skupiał na takich testach, które klikają w guziki... jednak kiedyś pracowałem jako tester manualny i przez 8h godzin dziennie wykonywałem tylko polecenia ze scenariusza kliknij w przycisk znajdź lekarza, kliknij umów wizytę, sprawdź czy jest umówiona. To była masowa strata czasu. Teraz takie rzeczy się automatyzuje. To samo może zrobić komputer. Tylko, że to była aplikacja bardzo formularzowa, oparta w 100% na klikaniu przycisków, wypełnianiu pól tekstowych, wybieraniu elementów z listy. Więc przy tego rodzaju rzeczach testy klikające w guziki mogą się sprawdzić.

No ale przecież nie wszystkie aplikacje tak wyglądają. Jak GUI jest bardziej zaawansowane wizualnie i bardzo interaktywne, to często łatwiej ręcznie przetestować. Szczególnie, że człowiek może zobaczyć, że coś nie gra estetycznie albo jest jakiś bug, którego nie wykryją testy.

Czyli - różne testy (unitowe, e2e, manualne) się przydadzą, w zależności od charakteru tego, co chcemy przetestować w danym momencie.

LukeJL napisał(a):

Riddle napisał(a):

qwerp12 napisał(a):

Wszystko super jednak czuję, że coś jest nie tak, ponieważ bardzo mi zależało na pisaniu testów automatyzujących Cypress / Playwright, jednak tech lead jest bardzo przeciwny, bo nie widzi senesu w testach, które "naśladują pracę usera, który klika sobie w guziki".

Moim zdaniem developerzy powinni enkapsulować logikę tak, żeby dało się do nich pisać testy unitowe, które pisze się łatwo i przyjemnie. Problem jest w tym, że w tego typu apkach webowych ludzie czasem wrzucają tę logikę luzem do komponentów. I to jest problem. Bo jak logika jest w komponencie, to zaczynasz testować całe komponenty, a nie funkcje, klasy...

GUI się ciągle zmienia oraz trudno je przetestować z automatu w sensowny sposób, więc ja bym dużo się nie skupiał na takich testach, które klikają w guziki... jednak kiedyś pracowałem jako tester manualny i przez 8h godzin dziennie wykonywałem tylko polecenia ze scenariusza kliknij w przycisk znajdź lekarza, kliknij umów wizytę, sprawdź czy jest umówiona. To była masowa strata czasu. Teraz takie rzeczy się automatyzuje. To samo może zrobić komputer. Tylko, że to była aplikacja bardzo formularzowa, oparta w 100% na klikaniu przycisków, wypełnianiu pól tekstowych, wybieraniu elementów z listy. Więc przy tego rodzaju rzeczach testy klikające w guziki mogą się sprawdzić.

No ale przecież nie wszystkie aplikacje tak wyglądają. Jak GUI jest bardziej zaawansowane wizualnie i bardzo interaktywne, to często łatwiej ręcznie przetestować. Szczególnie, że człowiek może zobaczyć, że coś nie gra estetycznie albo jest jakiś bug, którego nie wykryją testy.

Czyli - różne testy (unitowe, e2e, manualne) się przydadzą, w zależności od charakteru tego, co chcemy przetestować w danym momencie.

Na mnie nic nie działa!

Najlepiej skupić się na sugerowanych narzędziach, takich jak Vitest i Vue Test Utils, ale rozważ Cypress/Playwright do równoległego szkolenia i przyszłych projektów.