Code review aplikacji napisanej w Reakcie przez junior developera (część 8/10 - testy)

Moim gościem był Mati, junior developer, który w ramach nauki stworzył aplikację - listę zakupów. W nagraniu rozmawiamy o tym jak testować aplikację, a w dalszej części nagrania przechodzimy do części praktycznej. Zapraszam do oglądania!

Linki:

00:00:00 - start
00:01:04 - wstęp
00:01:47 - w następnych odcinkach
00:05:46 - co warto testować?
00:08:24 - odpowiedzi na pytania
00:08:34 - czy dodawanie data-testid w komponentach ma sens?
00:10:49 - w jaki sposób mockować providery w komponentach?
00:13:10 - do czego można wykorzystać klasy w testach?
00:29:03 - jak przekonać członków zespołu do pisania testów?
00:41:13 - w jaki sposób podchodzić do testów w pobocznym projekcie?
00:45:05 - czy warto testować hooki?
00:52:36 - czy powinniśmy testować biblioteki?
00:54:44 - jak testować API?
00:56:33 - co to znaczy “testować zachowanie”?
01:02:28 - czy w komercyjnych projektach zawsze pisze się testy?
01:03:52 - Jakie biblioteki były najtrudniejsze do przetestowania?
01:06:01 - których bibliotek najlepiej używać do testów?
01:08:58 - code review
01:19:05 - część praktyczna - co będziemy testować w dzisiejszym odcinku?
01:24:22 - czy tworzyć nowe branche podczas pracy?
01:26:10 - różne sposoby testowania komponentów
01:28:59 - unit testy vs integracyjne
01:33:02 - co możemy przetestować w komponencie?
01:37:32 - mockowanie komponentu
01:44:41 - test dla main-view component
01:46:00 - czy DRY w testach ma zastosowanie?
01:47:42 - zasada AAA/GWT
01:48:33 - czego powinien dotyczyć expect?
01:51:19 - testu ciąg dalszy
02:04:40 - nazywanie zmiennych w testach
02:08:55 - użycie mocka do sprawdzenia przekazanych parametrów
02:25:36 - naprawa mocków
02:36:55 - jak nazywać testy?
02:57:19 - naprawa pozostałych testów
03:15:04 - zakończenie

[olgak]

Swietny content! Komentarz dla zasiegu, bo warto.

[dikamilo]

FindByTestId zwraca promise i go resolwuje gdy element jest znaleziony lub rejektuje z domyślnym timeoutem gdy nie znaleziono, więc expect po tym nie ma sensu. W tym wypadku zamiast findyBy można użyć queryBy wtedy dostajemy element albo nulla.

[dikamilo]

Nie jestem do końca przekonany czy takie betonowanie testów mockami to doby pomysł w kwestii utrzymania aplikacji przy większych zmianach. Tutaj mając styled components oraz tłumaczenia, w zasadzie każdy komponent w testach będzie wymagać sporej ilości mockow, a gdy będziemy chcieli faktycznie coś przetestować w styled komponencie bo przyjmuje propsy i renderuje inaczej content to trzeba będzie się nagłowic z mockowanjem poprawnie komponentu itp. Moze lepiej jednak było by nadpisać metodę render na naszą własną która by wrapowala to co renderujemy w nasze providery np. theme, language itp. z jakimiś domyślnymi wartościami theme, języka itp. dzięki czemu nie trzeba by było potem mockowac nieistotnych rzeczy w samych testach.