Pytania rekrutacyjne z testowania z odpowiedziami
Jest i Vitest, React Testing Library, mocki i MSW, Playwright i Cypress, piramida testów: co, jak i na jakim poziomie testować.
228 pytań na rozmowę rekrutacyjną z tematu Testowanie z odpowiedziami i wyjaśnieniami - poziomy Junior, Middle i Senior. Przykładowe pytania, testy online i zadania z kodu.
- Jest
- Vitest
- Testing Library
- Mocks
- Playwright
- Cypress
Pytania według poziomu
Junior
Podstawowe pojęcia i składnia · 50 pytań
Middle
Praktyka, niuanse i optymalizacja · 50 pytań
Senior
Architektura, mechanizmy wewnętrzne, przypadki brzegowe · 50 pytań
Przykładowe pytania
Kilka pytań z każdego poziomu z poprawną odpowiedzią i wyjaśnieniem.
Testowanie · Junior
- Jaki jest główny cel testów automatycznych?
Poprawna odpowiedź: Dać pewność, że kod działa i będzie działał po zmianach
Testy mogą pokazać obecność błędów, ale nie ich brak. Ich wartość to szybka informacja zwrotna i bezpieczny refaktoring: jeśli zachowanie się zepsuje, test padnie, zanim zauważą to użytkownicy.
- Co sprawdza test jednostkowy (unit)?
Poprawna odpowiedź: Mały, odizolowany fragment kodu - funkcję, hook lub komponent - sam w sobie
Testy jednostkowe są szybkie i dokładnie wskazują miejsce awarii. Ich ograniczenie: nie pokazują, czy części działają razem.
- Co sprawdza test integracyjny?
Poprawna odpowiedź: Że kilka modułów poprawnie działa razem - np. formularz z walidacją i wywołaniem API
We frontendzie test integracyjny zwykle renderuje całą funkcjonalność (kilka komponentów, stan, router) i mockuje tylko granicę sieciową.
- Czym jest test end-to-end (E2E)?
Poprawna odpowiedź: Testem, który steruje prawdziwą aplikacją w przeglądarce jak użytkownik - przez UI, API i bazę danych
Testy E2E dają najwięcej pewności, ale są wolniejsze i bardziej kruche. Typowe narzędzia to Playwright i Cypress.
Testowanie · Middle
- Czym różnią się
findBy…iwaitFor?Poprawna odpowiedź:
findByczeka na pojawienie się jednego elementu;waitForponawia dowolny callback, aż przestanie rzucać błądfindByRole(...)to dosłowniewaitFor(() => getByRole(...)). Do czekania na element używajfindBy, do innych asercji -waitFor. - Jak poczekać, aż zniknie wskaźnik ładowania?
Poprawna odpowiedź:
await waitForElementToBeRemoved(() => screen.queryByRole("progressbar"))Helper wymaga, żeby element był obecny na początku, i czeka, aż zapytanie zwróci
null. - Co zwykle oznacza ostrzeżenie „An update to Component inside a test was not wrapped in act(...)”?
Poprawna odpowiedź: Stan zmienił się po tym, jak test przestał czekać - np. żądanie zakończyło się po ostatniej asercji
RTL już opakowuje
renderi zdarzenia wact. Zwykle rozwiązaniem jest poczekanie na końcowy stan UI przezfindBy/waitFor, a nie ręczne dodawanieact. - Jak przetestować pole wyszukiwania z debounce?
Poprawna odpowiedź: Włączyć fake timery, wpisać tekst, przesunąć czas o opóźnienie debounce i sprawdzić żądanie/wynik
Fake timery sprawiają, że test jest szybki i deterministyczny. Prawdziwe czekanie spowalnia zestaw i nadal daje wyścigi.
Testowanie · Senior
- Jak zdecydować, na którym poziomie piramidy/trofeum umieścić test?
Poprawna odpowiedź: Na najniższym poziomie, który wciąż wyłapie interesującą cię awarię z wystarczającą pewnością
Jeśli błąd wyłapie test jednostkowy lub integracyjny, dublujący test E2E tylko dodaje kosztu. E2E służy do tego, czego niższe poziomy nie widzą: prawdziwych połączeń, wdrożenia, integracji zewnętrznych.
- Dlaczego artykuł Google „Just Say No to More End-to-End Tests” ostrzega przed opieraniem się na E2E?
Poprawna odpowiedź: Porażki E2E przychodzą późno, trudno je zlokalizować i często są niestabilne, więc informacja zwrotna jest słaba
Dobre testy są szybkie, niezawodne i izolują błąd. Zestaw złożony głównie z E2E zawodzi we wszystkich trzech punktach.
- Czym jest „testing honeycomb” i gdzie się go stosuje?
Poprawna odpowiedź: Kształtem dla mikroserwisów: głównie testy integracyjne serwisu przez jego API, mało testów jednostkowych szczegółów implementacji i mało testów zintegrowanych
Model Spotify pasuje do serwisów, których złożoność leży w interakcjach, a nie w logice wewnętrznej.
- Na czym opierają się „rozmiary testów” Google (small, medium, large)?
Poprawna odpowiedź: Na zasobach, z których test może korzystać: small - jeden proces bez I/O; medium - jedna maszyna, localhost; large - cokolwiek, łącznie z systemami zdalnymi
Rozmiary opisują ograniczenia, które czynią testy szybkimi i deterministycznymi - niezależnie od sporów o nazwy „unit/integracyjny”.
Testy łączone z tym tematem
Pytania z kilku tematów naraz - jak na rozmowie rekrutacyjnej na konkretne stanowisko.
Zadania z kodu
Napisz rozwiązanie prosto w przeglądarce, a testy od razu je sprawdzą. Klasyka rozmów rekrutacyjnych: debounce, throttle, deepClone, Promise.all, EventEmitter, cache LRU i inne.
Otwórz zadania →