← Wszystkie tematy W 49% ogłoszeń · 23 z 47 ogłoszeń frontend React

Testy jednostkowe i komponentowe

Sprawdzanie każdego klocka osobno

Testy jednostkowe i komponentowe są w 23 z 47 ogłoszeń, zwykle jako Jest/Vitest + React Testing Library. Klasyczne pytanie brzmi: co właściwie testujesz w komponencie?

Przerobione Opanowane 0 z 5 pytań

Ucz się z Claude Wytłumacz od zera Próbna rozmowa Zadanie praktyczne Ściąga na 1 stronę

Co piszą w ogłoszeniach

„praktyczna znajomość React.js, w tym React Hooks, Custom Hooks, Context API, Vite, Vitest/Jest, React Hook Form oraz Fetch/Axios – minimum 5 lat doświadczenia lub 8 projektów”
Randlab · React Developer – (K/M/N)
„Experience with front-end testing frameworks such as Jest, React Testing Library, or Cypress.”
Capco Poland · Front-End Engineer - React (Payments)
„Minimum 5 lat doświadczenia w pracy z React.js, w tym znajomość React Hooks, Custom Hooks, Context API, Vite, Vitest/Jest, React Hook Form oraz Fetch/Axios,”
GET IT TOGETHER Sp. z o.o. · Frontend Developer (React)

Scena · co testować

Dwóch kontrolerów zabawek

Mamy zabawkę: licznik cukierków z przyciskiem „Dodaj”. Sprawdzają ją dwaj kontrolerzy. Pierwszy rozkręca zabawkę i patrzy, czy w środku są te same śrubki, co wczoraj. Drugi bawi się nią jak dziecko: naciska przycisk i patrzy, czy pojawił się cukierek. Teraz przerób środek zabawki (refaktor) albo naprawdę ją zepsuj i zobacz, który kontroler mówi prawdę.

Licznik.tsx

Kontroler 1 · szczegóły implementacji

Kontroler 2 · zachowanie (Testing Library)

bez zmian refaktor (działa tak samo) błąd: dodaje 2

Wybierz zmianę i uruchom testy.

Porównajmy

Rozkręcać czy się bawić?

	Testy implementacji	Testy zachowania
Na co patrzą?	Na śrubki w środku.Stan komponentu, nazwy klas, czy wywołano wewnętrzną funkcję.	Na to, co widzi i robi dziecko.Tekst, role, etykiety: `getByRole("button", {name: "Dodaj"})`.
Refaktor	Krzyczą, choć wszystko działa.Fałszywe alarmy, testy do poprawiania przy każdej zmianie.	Milczą, bo dla dziecka nic się nie zmieniło.Test przeżywa zmianę implementacji.
Prawdziwy błąd	Czasem go przegapią.Sprawdzają mechanizm, nie wynik.	Łapią go od razu.Sprawdzają wynik widoczny dla użytkownika.
Czekanie na coś	Ręczne timery i mocki.`jest.advanceTimersByTime` wszędzie.	Czekają, aż coś się pojawi.`findBy…` / `waitFor`, sieć mockowana przez MSW.
Dostępność gratis	Nie.Selektory po klasach.	Tak: jak test nie znajdzie przycisku po roli, czytnik ekranu też nie.Kolejność zapytań: role → label → text → testid.

Baw się jak dziecko

Testuj to, co widzi użytkownik, a nie śrubki w środku.

getBy / queryBy / findBy

getBy: musi być teraz. queryBy: sprawdzam, że czegoś nie ma. findBy: poczekam, aż się pojawi.

Piramida

Dużo szybkich testów małych klocków, mniej integracyjnych, kilka E2E dla najważniejszych ścieżek.

Sprawdź się

Pytania z rozmów

Najpierw odpowiedz na głos, dopiero potem rozwiń odpowiedź.

Co testujesz w komponencie React, a czego nie? (zachowanie vs implementacja)

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Bawię się zabawką jak dziecko: naciskam i patrzę, co się stało. Nie rozkręcam jej, żeby liczyć śrubki.

Na rozmowę: Testuję to, co widzi i robi użytkownik: renderowany tekst, reakcję na kliknięcie i wpisywanie, stany ładowania, błędów i pustej listy, wywołanie callbacku z właściwymi danymi, dostępne nazwy. Nie testuję stanu wewnętrznego, nazw klas CSS, liczby renderów ani tego, czy wywołano prywatną funkcję, bo to daje fałszywe alarmy przy refaktorze i nie łapie prawdziwych błędów. Nie testuję też bibliotek (czy React renderuje).

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

getBy vs queryBy vs findBy w Testing Library: kiedy który?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: getBy: „to musi tu być teraz”. queryBy: „sprawdzam, że tego nie ma”. findBy: „poczekam, aż się pojawi”.

Na rozmowę: getBy* rzuca, gdy elementu nie ma albo jest ich kilka. Używam go do asercji obecności. queryBy* zwraca null zamiast rzucać, więc służy do sprawdzania nieobecności: expect(queryByText(...)).not.toBeInTheDocument(). findBy* zwraca Promise i ponawia do timeoutu, więc pasuje do elementów pojawiających się asynchronicznie (po fetchu). Warianty *AllBy* dla wielu elementów. Kolejność wyboru zapytań: ByRole → ByLabelText → ByText → ByTestId na końcu.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Jak testować kod asynchroniczny i zapytania do API? (MSW, mocki)

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Zamiast prawdziwej kuchni stawiasz kuchnię na niby, która zawsze odpowiada tym, czym chcesz.

Na rozmowę: Sieć mockuję na poziomie HTTP przez MSW (Mock Service Worker): handler dla GET /api/users zwraca dane testowe, a w konkretnym teście nadpisuję go na 500, żeby sprawdzić stan błędu. Komponent i hooki działają wtedy jak w produkcji, łącznie z fetch i TanStack Query. Na wynik czekam przez findBy lub waitFor, nie przez setTimeout. Timery: vi.useFakeTimers() i advanceTimersByTime. Mockowanie modułów (vi.mock) zostawiam dla rzeczy naprawdę zewnętrznych.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Jak napisać test custom hooka?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Na rozmowę: Najlepiej przez komponent, który go używa, bo wtedy testuję zachowanie. Gdy hook jest generyczny (useDebounce, useLocalStorage), używam renderHook z @testing-library/react: const { result, rerender } = renderHook(() => useCounter(0)), zmiany w act(() => result.current.inc()), asercja na result.current. Hooki z kontekstem dostają wrapper z providerem (np. QueryClientProvider ze świeżym klientem na każdy test, retry: false).

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Piramida testów: ile unit, ile integracyjnych, ile E2E?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Dużo szybkich sprawdzianów pojedynczych klocków, mniej sprawdzianów całych zestawów i kilka sprawdzianów całego miasta.

Na rozmowę: Klasyczna piramida: dużo unit, mniej integracyjnych, najmniej E2E. Na froncie często mówi się o „trofeum” (Kent C. Dodds): podstawa to statyczna analiza (TS, ESLint), najwięcej testów integracyjnych komponentów z RTL i MSW, mniej czystych unit dla logiki, a kilka E2E w Playwright dla krytycznych ścieżek (logowanie, zakup, płatność). Liczy się pewność za rozsądny koszt utrzymania, a nie procent pokrycia.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

Poziom wyżej

Wersja dla seniora

Tak wyglądają pytania na seniora i leada: nie ma jednej dobrej odpowiedzi, liczy się to, jak ważysz kompromisy i czy mówisz o skali, ryzyku i ludziach.

Przypadek 1

Zespół bez testów i rok długu

Dołączasz jako senior do zespołu, który przez rok nie pisał testów, bo „nie było czasu”. Każde wdrożenie kończy się poprawkami na produkcji. Masz 20% czasu zespołu na poprawę jakości.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy umiesz ustalić priorytety na podstawie ryzyka, a nie pokrycia
Czy proponujesz strategię, którą zespół utrzyma
Czy mierzysz efekt

Odpowiedź seniora

Nie zaczynam od celu pokrycia. Zaczynam od mapy ryzyka: które obszary psują się najczęściej (dane z incydentów i bugów) i które są najważniejsze dla biznesu (koszyk, płatność, logowanie). Tam najpierw idą testy, które dają najwięcej pewności: kilka testów E2E w Playwright dla krytycznych ścieżek jako siatka bezpieczeństwa i testy integracyjne komponentów z RTL i MSW.

Zasada od dziś: każdy naprawiany bug dostaje test, który go odtwarza, a nowy kod ma testy w tym samym PR. Do tego statyczna analiza (TypeScript strict, ESLint) jako najtańsza warstwa. Infrastruktura musi być przyjemna: szybki Vitest, gotowe helpery renderowania z providerami, fabryki danych testowych i handlery MSW, żeby pisanie testu zajmowało minuty.

Mierzę liczbę bugów z produkcji, czas naprawy i liczbę hotfixów, a nie samo pokrycie. Pokazuję zespołowi wyniki co miesiąc.

Typowe wpadki

Cel „80% pokrycia w kwartał”
Pisanie testów do istniejącego kodu losowo, plik po pliku
Wprowadzenie ciężkiej infrastruktury, której nikt nie lubi używać

Dopytają o

Jak przekonasz produkt, że to się opłaca?
Co zrobisz z kodem, którego nie da się przetestować bez refaktoru?
Kiedy test E2E, a kiedy integracyjny?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 2

Tysiąc snapshotów, które wszyscy aktualizują bez czytania

Projekt ma 1200 testów snapshot. Przy każdej zmianie w design systemie kilkaset z nich pada, a programiści uruchamiają jest -u i commitują wynik. Ostatnio przepuściło to prawdziwy błąd w cenie.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy rozumiesz, dlaczego duże snapshoty nie chronią
Czy znasz lepsze alternatywy dla różnych celów
Czy umiesz przeprowadzić zmianę w zespole

Odpowiedź seniora

Duże snapshoty całych komponentów testują wszystko i nic: każda zmiana stylu je łamie, więc przestają być czytane. Zamieniam je stopniowo na asercje zachowania i treści (getByRole, getByText z konkretną ceną), a tam, gdzie chodzi o wygląd, na testy wizualne (Chromatic, Playwright toHaveScreenshot), które pokazują różnicę obrazem i wymagają akceptacji w review.

Snapshoty zostają tam, gdzie mają sens: małe, celowane, inline (toMatchInlineSnapshot) dla czystych danych wyjściowych, np. wyniku serializacji lub komunikatu błędu. Reguła ESLint (jest/no-large-snapshots) ogranicza rozmiar.

Migracja zaczyna się od testów, które padają najczęściej. Błąd w cenie dostaje test zachowania od razu.

Typowe wpadki

Usunięcie wszystkich snapshotów bez zastąpienia
Dalsze jest -u w PR bez review
Testy wizualne bez stabilnego środowiska renderowania

Dopytają o

Jak ustabilizujesz testy wizualne (fonty, animacje)?
Kiedy snapshot jest dobrym testem?
Jak wyjaśnisz zmianę zespołowi?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 3

Refaktor modułu rozliczeń, którego nikt nie rozumie

Moduł liczenia faktur ma 3 tys. linii, ciągi warunków i zero testów. Trzeba go przepisać, bo blokuje nowe funkcje, ale każda pomyłka to błędne faktury dla klientów.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy znasz testy charakteryzujące (characterization tests)
Czy umiesz refaktorować małymi krokami pod osłoną testów
Czy myślisz o weryfikacji na danych produkcyjnych

Odpowiedź seniora

Najpierw zamrażam obecne zachowanie testami charakteryzującymi: zbieram realne, zanonimizowane dane wejściowe (np. tysiąc faktur z produkcji) i zapisuję obecne wyniki jako oczekiwane, nawet jeśli wyglądają podejrzanie. Do tego testy oparte na właściwościach (fast-check): suma pozycji równa się sumie faktury, VAT nigdy ujemny.

Refaktor idzie małymi krokami: wydzielenie czystych funkcji, nazwanie przypadków, zastąpienie warunków tabelą reguł, z uruchomieniem testów po każdym kroku. Podejrzane wyniki zapisuję jako pytania do biznesu, a nie poprawiam po cichu.

Na koniec nowy moduł działa równolegle ze starym w trybie cienia: oba liczą fakturę, różnice są logowane, a klient dostaje wynik starego. Przełączam, gdy przez ustalony czas różnic nie ma.

Typowe wpadki

Przepisanie od zera i testowanie ręczne
Poprawianie „oczywistych błędów” w trakcie refaktoru
Testy tylko na wymyślonych danych

Dopytają o

Jak zanonimizujesz dane produkcyjne do testów?
Co zrobisz, gdy tryb cienia pokaże różnicę?
Jak podzielisz tę pracę w zespole?

Zapytaj Claude Rozwiń case Zagraj interviewera