[AntyKuc]

Jak podchodzicie do testowania kodu frontowego? Przyznam szczerze, że spotkałem się już z wieloma podejściami, ale chyba najbardziej podzielam to o których pisze twórca RTLa, czyli żeby test komponentu odzwierciedlał jego realne użycie przez end usera. Więc piszemy głównie testy integracyjne wspierając się tylko unitami.

#programista15k #programowanie #frontend #react #vuejs #angular

[Pasterz30]

@AntyKuc RTL i uzywasz zgodnie z accessibility czyli tak jak ta biblioteka zostala zaprojektowana. Jest kilka waznych zasad:

1. Nie testuj styli, jakis wizualnych aspektow - od tego sa visual testy
2. Nie uzywaj dataTestId - to dodaje smieciowy kod i wymusza implementacje - testy powinny dzialac praktycznie niezaleznie od implementacji ficzera, liczy sie efekt
3. Nie sprawdzaj czegos co jest juz testowane gdzie indziej - jezeli Twoj komponent renderuje inny komponent ktory ma

[xxx_JOBOL_PL_xxx]

@AntyKuc: Testy integracyjne na froncie to testy komponentu, czy źle to rozumiem?

[AntyKuc]

@xxx_JOBOL_PL_xxx: Np. test Forma - jest to jeden komponent, ale składa się pod spodem z wielu mniejszych komponentów, requestów do api, mapperów, stora itd. Więc testujesz większą całość - no to test integracyjny. Ale faktycznie na froncie to jest śliskie z tym czy test jest jednostkowy czy integracyjny.

[AntyKuc]

@Pasterz30: Zgadzam się ze wszystkim co napisałeś, ale jednak czasami tego test-id trzeba dodać, bo po prostu nie masz innego wyboru. Zwłaszcza jeżeli w twoim korpo mają wywalone na accessibility XD

[Pasterz30]

@AntyKuc: trust me, nie trzeba. Mogliby to w-----c. Po prostu brakuje Ci jakiegos atrybutu role albo labela w HTMLu.

[mirasKo-Kalwario]

Nie uzywaj dataTestId -

@Pasterz30: to czego używac? Mam np checkboxa który po kliknięciu dodaje input do forma (albo ukrywa po odkliknięciu) jak bys to przetestował bez data-testId na inpucie ? zakladając że takich elementów mam kilka i ciężko zgadnąc ID inputa

[Pasterz30]

@mirasKo-Kalwario checbox jest olabelowany wiec screen.getByLabel lub screen.getByRole z drugim parametrem { name: }. Daj kod to Ci pokaze

[mirasKo-Kalwario]

@Pasterz30: a gdyby pokazywany / ukrywany był div to też po jakimś atrybucie byś go wyszukiwał?

[Nighthuntero]

2. Nie uzywaj dataTestId - to dodaje smieciowy kod i wymusza implementacje - testy powinny dzialac praktycznie niezaleznie od implementacji ficzera, liczy sie efekt

@Pasterz30: @AntyKuc @mirasKo-Kalwario

P---------e, właśnie jak najbardziej używa się testID, szczególnie jak masz wiele podobnych pół i i18n/localization do pokrycia

https://playwright.dev/docs/locators#locate-by-test-id

[Pasterz30]

@Nighthuntero: gosciu ale rozmawiamy o React Testing Library i unit testach a nie e2e
@mirasKo-Kalwario wszystko jest do zrobienia tylko pokaz przyklad kodu bo moze to nie kwestia testu tylko Twojego kodu ktory nie jest optymalny. Ciezko gdybac bez przykladu

[mirasKo-Kalwario]

@Pasterz30: nie ma kodu, wymyslam przykład zeby zrozumieć bo dla mnie testId to pójscie na łatwizne która oszczędza czas. Wiadomo najlepiej testować PoV usera i próbować robić interakcje z elementami tak jak robi to user czyli szukac inputów po name, role, label itd ale jakos łatwiej mi zrobic po testId i sprawdzic czy element ma odpowiednie role, name, aria itd.

Może to i antypattern ale czy taki bardzo szkodliwy? Siedze

[Pasterz30]

@mirasKo-Kalwario czy jest okej to jest kwestia do dluzszej dyskusji, napewno w unitach to nie jest okej (mozesz o tym poczytac nawet w ich dokumentacji) natomiast to ze wydaje Ci sie ze jest szybciej to jest miecz obosieczny bo wystarczy ze zmienisz lekko implementacje i test Ci wywali i ttzeba poprawiac i test i dodawac datatestid. Jezeli nie jestes w stanie inaczej tego zrobic to znaczy ze nie tyle test jest

[tytanowyborsuk]

@AntyKuc: My testujemy na produkcji.