Ćwiczenie: znajdź błędy formularza rejestracji

Uruchom laboratorium

W tym serwisie wystarczy przycisk „Uruchom laboratorium” powyżej. Instrukcja uruchomienia przez terminal poniżej dotyczy osobnej pracy na źródłowych plikach ćwiczenia.

Cel: przygotuj przypadki testowe, porównaj wynik interfejsu z odpowiedzią serwera i napisz jedno odtwarzalne zgłoszenie błędu. Laboratorium v1.0 zawiera cztery celowe defekty. To dane i konta demonstracyjne; nie wpisuj prawdziwych haseł ani adresów.

Przeczytaj lekcję · Checklista Markdown · Checklista PDF

Uruchomienie

W terminalu otwartym w katalogu projektu wykonaj node tools/serwer-lekcji.cjs. Potrzebujesz polecenia node; nie instalujesz pakietów npm.
Otwórz http://127.0.0.1:8787/content/cwiczenia/formularz-rejestracji/lab.html. Plik laboratorium wymaga serwera; samo otwarcie przez file:// nie uruchamia API.
Otwórz DevTools (Ctrl+Shift+I na Windows), panel Network, filtr Fetch/XHR. Wpisz register, aby obserwować wysyłki formularza.
Kliknij „Resetuj ćwiczenie”. Początkowo istnieje tylko zajety@example.com. Panel „Konta w pamięci serwera” pokazuje adresy i wybór marketingu. GET /api/state udostępnia ten sam stan.

Konta istnieją w RAM do resetu lub zakończenia serwera. Hasła nie są przechowywane, nie ma wysyłania poczty ani aktywacji. Zatrzymasz serwer klawiszami Ctrl+C w terminalu. Odświeżenie strony nie resetuje kont.

Wymagania

E-mail wymagany, w projektowym formacie local@domain.tld, z obcięciem spacji z obu końców. Hasło: 12–64 widoczne znaki ASCII (!–~), bez spacji; bez wymogu wielkiej litery, cyfry lub symbolu. Powtórzenie identyczne. Regulamin DEMO wymagany. Marketing dobrowolny, początkowo wyłączony. Utworzenie konta: HTTP 201; duplikat: 409; odrzucenie danych przez backend: 422. Awaria 503 i brak połączenia nie mogą pokazywać sukcesu. Podczas żądania przycisk blokuje ponowną wysyłkę.

Zadanie

Zapisz środowisko i datę. Przygotuj test poprawny, granice 11/12/64/65 znaków, różne powtórzenie, pusty e-mail, brak regulaminu, duplikat oraz dwa warianty marketingu. Przed niezależną próbą resetuj ćwiczenie. W każdej próbie zmieniaj jedną badaną właściwość, a pozostałe dane pozostaw poprawne.

Najpierw sprawdź stan początkowy formularza. Dla poprawnej ścieżki użyj qa@example.com, dwóch identycznych abcdefghijkl, zaakceptuj regulamin i wyłącz marketing. Porównaj komunikat, status żądania i stan kont. Przy granicach stosuj identyczną wartość w obu polach hasła.

Włącz przełącznik „Błąd serwera 503” i wyślij poprawne dane. Następnie wykonaj osobny test Offline w DevTools, po wcześniejszym wczytaniu strony. Przywróć No throttling przed resetowaniem i kolejnymi próbami. Sprawdź też szybkie podwójne kliknięcie w trakcie około 500 ms oczekiwania.

Do każdego wyniku dodaj dowód: komunikat, status i odpowiedź z Network, zmianę lub brak zmiany stanu. Jeśli nie powstało żądanie, zapisz „blokada w formularzu”; nie przypisuj odrzucenia serwerowi. Wybierz jeden defekt i przygotuj raport według wzoru z lekcji.

Opcjonalnie: test samego backendu

Poniższy kod wpisz w konsoli DevTools na stronie laboratorium. To syntetyczne dane wysyłane do własnego lokalnego demo. Omija walidację formularza. Przed próbą użyj resetu; po niej odśwież stan przy użyciu /api/state lub strony, aby zobaczyć zmianę kont.

const response = await fetch('/api/register', {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({
    email: 'qa@example.com',
    password: 'abcdefghijkl',
    confirm: 'abcdefghijkl',
    terms: true,
    marketing: false,
    simulate503: false
  })
});
console.log(response.status, await response.json());

Powyższe poprawne dane powinny zwrócić 201. W kolejnych niezależnych próbach zmień tylko email na pusty tekst albo terms na false: oczekuj 422. Następnie sprawdź 11 znaków w password i confirm oraz różne 12-znakowe confirm. Oczekuj odrzucenia obu wariantów; wadliwa wersja demo celowo je przyjmuje. Przy ponownym wykonaniu kodu w tej samej konsoli nadaj zmiennej inną nazwę lub odśwież kartę, jeśli narzędzie zgłasza ponowną deklarację. Nie wklejaj nieznanych skryptów do konsoli innych serwisów.

Podpowiedzi

Sukces sprawdzaj w trzech miejscach: UI, odpowiedź HTTP, stan kont.
Sprawdź wartość tuż poniżej minimum, a nie wyłącznie bardzo krótkie hasło.
Niezgodność pól badaj na dwóch hasłach spełniających regułę długości.
Wymaganie dotyczące wartości domyślnej sprawdza się przed edycją formularza.

Rozwiązanie — przeczytaj po własnych próbach

Poniższe wyniki opisują celowo zaprogramowane defekty v1.0. Nie zastępują Twoich obserwacji ani protokołu weryfikacji technicznej.

Defekt	Dane i czynność	Oczekiwane zachowanie	Celowy wynik wadliwej wersji
A — błędne minimum	Po resecie użyj `qa@example.com`, `abcdefghijk` w obu polach, regulamin włączony, marketing wyłączony.	Odrzucenie 11 znaków; brak konta.	Frontend i backend przyjmują 11 znaków; HTTP 201 i nowe konto.
B — brak porównania	Po resecie hasło `abcdefghijkl`, powtórzenie `abcdefghijkm`; reszta poprawna.	Odrzucenie niezgodności; brak konta.	Frontend i backend nie porównują pól; HTTP 201 i nowe konto.
C — wartość domyślna marketingu	Otwórz lub zresetuj formularz; nie zmieniaj checkboxa marketingu.	Marketing wyłączony.	Marketing jest zaznaczony. Sam brak wyboru marketingu po jego ręcznym wyłączeniu nie blokuje rejestracji.
D — fałszywy sukces	Po resecie włącz „Błąd serwera 503” i wyślij poprawne dane.	Komunikat błędu, brak konta.	Backend zwraca 503 bez utworzenia konta, lecz UI pokazuje „Konto zostało utworzone”.

Defekty A i B naruszają reguły danych w obu warstwach. C dotyczy stanu kontrolki przed wyborem użytkownika. D dotyczy interpretacji odpowiedzi przez frontend; sam backend w tym trybie nie tworzy konta. Brak połączenia jest odrębnym scenariuszem i nie jest celowym defektem.

Zadanie ukończysz, jeśli wskażesz cztery defekty z danymi pozwalającymi je odtworzyć, rozdzielisz oczekiwanie od obserwacji i przygotujesz jeden kompletny raport. Pozostałe sprawdzenia checklisty mogą ujawnić dodatkowe obserwacje; ta lekcja nie deklaruje pełnej zgodności demo z WCAG ani przydatności do produkcyjnej rejestracji.