← Wszystkie tematy W 32% ogłoszeń · 15 z 47 ogłoszeń frontend React

Testy E2E

Robot, który klika jak prawdziwe dziecko

Testy E2E są w 15 z 47 ogłoszeń, zwykle Playwright albo Cypress. Najczęściej pytają o niestabilne testy i o to, co w ogóle warto testować na tym poziomie.

Przerobione Opanowane 0 z 3 pytań

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

Co piszą w ogłoszeniach

„Experience with front-end testing frameworks such as Jest, React Testing Library, or Cypress.”
Capco Poland · Front-End Engineer - React (Payments)
„Cypress”
Experis Manpower Group · Web Developer
„Develop and maintain automated tests using appropriate unit, integration, and end-to-end testing frameworks.”
DCV Technologies · Senior React Developer with Java backend experience

Scena · niestabilne testy

Robot, który klika jak prawdziwe dziecko

Robot otwiera prawdziwą przeglądarkę i kupuje lizaka, tak jak zrobiłoby to dziecko. Problem: sklep czasem odpowiada szybko, a czasem wolno. Robot z zegarkiem zawsze czeka pół sekundy i klika dalej, nawet jeśli nic się jeszcze nie pojawiło. Robot, który patrzy, czeka, aż element naprawdę będzie na ekranie. Uruchom każdego 20 razy.

waitForTimeout(500) auto-waiting (expect)

–

Uruchom 20 razy z zegarkiem, potem z patrzeniem.

Porównajmy

Playwright czy Cypress?

	Playwright	Cypress
Gdzie mieszka robot?	Poza przeglądarką, steruje nią z zewnątrz.Protokół CDP / WebDriver BiDi, Node.js.	W środku przeglądarki, obok aplikacji.Działa w tej samej pętli zdarzeń co aplikacja.
Przeglądarki	Chromium, Firefox, WebKit (Safari).	Głównie Chromium i Firefox.WebKit eksperymentalnie.
Wiele kart i domen	Bez problemu.Wiele kart, kontekstów, logowanie przez inną domenę.	Trudniej.Jedna karta, `cy.origin` do innych domen.
Czekanie	Lokatory same czekają.`await expect(page.getByText("Dziękujemy")).toBeVisible()`	Komendy same ponawiają.`cy.contains("Dziękujemy").should("be.visible")`
Wygoda	Trace viewer, równoległość, codegen.Szybki w CI, sharding.	Świetny podgląd na żywo i time-travel.Przyjemny przy pisaniu testów.

Nie zegarek, tylko oczy

Nigdy sleep(500). Czekaj, aż coś naprawdę się pojawi.

Szukaj jak człowiek

getByRole i getByText zamiast .btn-23 i div:nth-child(4).

Mało, ale ważne

E2E są wolne i drogie. Pokryj nimi zakup, logowanie i płatność, a resztę testami jednostkowymi.

Sprawdź się

Pytania z rozmów

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

Playwright vs Cypress: różnice?

Moja odpowiedź

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

Pokaż odpowiedź

Dla przedszkolaka: Robot Playwright stoi obok przeglądarki i nią steruje, a robot Cypress siedzi w środku, obok aplikacji.

Na rozmowę: Playwright steruje przeglądarką z zewnątrz (Node.js): Chromium, Firefox i WebKit, wiele kart, kontekstów i domen, równoległość i sharding z pudełka, trace viewer, codegen, async/await. Cypress działa w przeglądarce obok aplikacji: świetny tryb interaktywny z time-travel i podglądem, łańcuchowe API z automatycznym ponawianiem, ale ograniczenia przy wielu kartach i domenach, a równoległość w chmurze jest płatna. Do nowych projektów częściej wybiera się Playwright.

Umiem?

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

Skąd biorą się niestabilne (flaky) testy E2E i jak je naprawiasz?

Moja odpowiedź

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

Pokaż odpowiedź

Dla przedszkolaka: Robot z zegarkiem klika po pół sekundy, nawet jeśli sklep jeszcze nie odpowiedział. Robot, który patrzy, czeka, aż rzecz naprawdę się pojawi.

Na rozmowę: Przyczyny: sztywne czekanie (waitForTimeout), kruche selektory (klasy, nth-child), zależność od kolejności testów i współdzielonych danych, prawdziwe zewnętrzne API, animacje, strefy czasowe, za mało zasobów w CI. Naprawa: web-first asercje z auto-waitingiem (await expect(locator).toBeVisible()), lokatory po roli i tekście albo data-testid, izolacja (każdy test tworzy własne dane przez API, czysty storageState), mockowanie zewnętrznych usług (page.route), wyłączone animacje. Flaky test analizuję w trace, a nie „naprawiam” retry.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Jakie scenariusze warto pokryć E2E, a których nie?

Moja odpowiedź

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

Pokaż odpowiedź

Dla przedszkolaka: Robot sprawdza najważniejsze wycieczki po mieście: wejście, zakup i wyjście. Każdego krawężnika nie ogląda.

Na rozmowę: Krytyczne ścieżki biznesowe, które przynoszą pieniądze lub blokują użytkownika: rejestracja i logowanie, wyszukanie i zakup, płatność, kluczowy formularz, uprawnienia. Do tego smoke test po deployu. Nie testuję E2E wszystkich wariantów walidacji, przypadków brzegowych logiki ani wyglądu każdego komponentu, bo to szybciej i stabilniej robią testy jednostkowe, komponentowe i wizualne (Chromatic, Playwright screenshots). E2E są wolne i drogie w utrzymaniu, więc ma ich być mało, ale mają być pewne.

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

900 testów, 50 minut i nikt im nie ufa

Suite E2E w Cypressie ma 900 testów i trwa 50 minut. Co trzeci pipeline jest czerwony przez losowe błędy, więc ludzie klikają ponowne uruchomienie albo mergują mimo czerwonego. Masz trzy miesiące, żeby to naprawić.

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 mierzysz niestabilność zamiast zgadywać
Czy kwestionujesz, czy 900 testów E2E jest potrzebnych
Czy znasz techniki przyspieszenia: równoległość, sharding, izolacja
Czy przywracasz zaufanie procesem

Odpowiedź seniora

Najpierw dane: zbieram wyniki z ostatnich tygodni i dla każdego testu liczę wskaźnik niestabilności i czas. Zwykle 5% testów odpowiada za większość losowych błędów. Te idą do kwarantanny (oznaczone i uruchamiane osobno, nieblokujące) z właścicielem i terminem naprawy.

Potem piramida: przeglądam, co testy sprawdzają. Walidacje formularzy, warianty komponentów i logika wyliczeń schodzą do testów komponentowych i jednostkowych. E2E zostają dla ścieżek krytycznych, co często daje 150 zamiast 900.

Przyspieszenie i stabilność: sharding na kilka maszyn, przy migracji na Playwright równoległe workery w jednej maszynie, logowanie raz przez storageState zamiast przez UI w każdym teście, dane tworzone przez API, mockowanie zewnętrznych usług. Cel to poniżej 10 minut i niestabilność poniżej 1%. Gdy to osiągniemy, czerwony pipeline znowu blokuje merge bez wyjątków.

Typowe wpadki

Dodanie automatycznego retry 3 razy jako rozwiązania
Usuwanie niestabilnych testów bez zastąpienia
Przepisanie wszystkiego na Playwright bez zmiany podejścia

Dopytają o

Jak zdecydujesz, które testy usunąć?
Kto naprawia test w kwarantannie?
Jak pokażesz postęp zespołowi i managerowi?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 2

Dane testowe i izolacja środowisk

Testy E2E działają na wspólnym środowisku staging. Testy różnych zespołów modyfikują tych samych użytkowników i produkty, ktoś ręcznie zmienia dane, a testy uruchomione równolegle zabierają sobie nawzajem ostatnią sztukę towaru. Wyniki zależą od pory dnia.

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, że wspólne dane to główne źródło niestabilności
Czy znasz strategie: dane per test, seed, środowiska efemeryczne
Czy myślisz o sprzątaniu i koszcie

Odpowiedź seniora

Zasada: każdy test tworzy własne dane i nie zakłada niczego o stanie środowiska. Przygotowuję fixtures w Playwright, które przez API (albo specjalny endpoint testowy dostępny tylko na środowiskach testowych) tworzą użytkownika, produkt z odpowiednim stanem magazynu i koszyk z unikalnym prefiksem w nazwie. Po teście dane są usuwane albo wygasają same.

Dla PR-ów stawiamy środowiska efemeryczne: preview frontendu i backendu z bazą zasianą skryptem seed na starcie, zniszczone po zamknięciu PR-a. Testy uruchamiane na takim środowisku są powtarzalne. Staging zostaje dla testów integracyjnych przed wydaniem i jest chroniony przed ręcznymi zmianami w danych testowych.

Zależności zewnętrzne (płatności, maile, SMS) są zastąpione mockami lub trybem sandbox. Czas w testach kontroluję (page.clock w Playwright), żeby promocje i terminy nie psuły wyników.

Typowe wpadki

Wspólny testowy użytkownik dla wszystkich testów
Testy zależne od kolejności uruchomienia
Czyszczenie bazy przed każdym testem na wspólnym środowisku

Dopytają o

Jak zabezpieczysz endpoint do tworzenia danych, żeby nie trafił na produkcję?
Ile kosztuje środowisko efemeryczne i jak to uzasadnisz?
Jak testujesz migracje bazy razem z frontem?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 3

Testowanie płatności i integracji zewnętrznych

Najważniejsza ścieżka to zakup z płatnością przez zewnętrzną bramkę z 3D Secure, potem mail z potwierdzeniem i faktura z zewnętrznego systemu. Test E2E tej ścieżki pada co kilka dni przez sandbox dostawcy, a raz błąd w integracji wyszedł dopiero na produkcji.

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 dzielisz testy na warstwy zamiast jednego wielkiego E2E
Czy znasz testy kontraktowe i mocki na poziomie sieci
Czy myślisz o monitoringu produkcji jako uzupełnieniu testów

Odpowiedź seniora

Jeden test przez całą zewnętrzną bramkę będzie zawsze niestabilny, więc dzielę odpowiedzialność. W głównym suite E2E bramkę zastępuję mockiem na poziomie sieci (page.route albo stub serwera), który symuluje sukces, odrzucenie, 3DS i timeout. Dzięki temu testuję nasze zachowanie we wszystkich wariantach szybko i stabilnie.

Zgodność z prawdziwym API dostawcy sprawdzam testami kontraktowymi (np. Pact albo walidacja odpowiedzi schematem) i osobnym, rzadszym testem na sandboksie dostawcy, który nie blokuje merge, ale alarmuje kanał zespołu. Maile sprawdzam przez przechwytywanie (Mailpit, MailHog) na środowisku testowym.

Na produkcji uzupełnieniem jest monitoring syntetyczny: co kilka minut skrypt przechodzi zakup na koncie testowym z prawdziwą małą płatnością zwracaną automatycznie, a alerty patrzą na odsetek udanych płatności. Błąd integracji, który wyszedł na produkcji, staje się nowym przypadkiem w mocku i w teście kontraktowym.

Typowe wpadki

Uzależnienie blokującego pipeline od sandboxa dostawcy
Mockowanie wszystkiego bez sprawdzania kontraktu z prawdziwym API
Brak monitoringu płatności na produkcji

Dopytają o

Jak zasymulujesz okno 3D Secure w Playwright?
Co zrobisz, gdy dostawca zmieni API bez ostrzeżenia?
Jak testujesz webhooki od bramki płatności?

Zapytaj Claude Rozwiń case Zagraj interviewera