Programowanie frontendu często zaczyna się, zanim backend jest gotowy do zwracania prawdziwych danych. Zamiast czekać na działające API, można wygenerować realistyczne testowe dane JSON w odpowiednim kształcie i od razu zacząć pracę.
Czym są dane mock
Mock JSON to wygenerowane, ale strukturalnie wiarygodne dane: imiona wyglądające jak prawdziwe imiona, daty we właściwym formacie, identyfikatory o odpowiednim wyglądzie. W przeciwieństwie do wartości testowych typu "test123", realistyczne mocki od razu pokazują, czy interfejs poprawnie obsługuje długie nazwy, puste pola czy konkretne formaty dat.
Do czego to potrzebne
- Rozpoczęcie budowy interfejsu, zanim zespół backendu skończy pracę nad API.
- Testowanie, jak interfejs zachowuje się przy dużej liczbie rekordów, bez potrzeby wypełniania prawdziwej bazy danych.
- Stworzenie dema lub prototypu bez ujawniania prawdziwych danych użytkowników.
- Pisanie testów automatycznych, które nie zależą od stanu zewnętrznej usługi czy bazy danych.
Polski kod pocztowy ma myślnik dokładnie w jednym miejscu
Polski kod pocztowy zapisuje się jako XX-XXX — dwie cyfry, myślnik, trzy cyfry (np. 00-001) — inaczej niż niemieckie czy francuskie 5-cyfrowe kody bez separatora. Numer telefonu z prefiksem +48 zwykle zapisuje się w parach cyfr (+48 601 234 567). Szablon mocka generujący {{postalCode}} jako pięć cyfr bez myślnika da wartość, która wygląda na kod pocztowy, ale żaden Polak jej tak nie zapisze — a walidacja pola po stronie frontendu, jeśli sprawdza wzorzec regex, odrzuci taki mock jako niepoprawny.
Na co zwrócić uwagę
Dane mock dobrze odtwarzają kształt i typy prawdziwych danych, ale nie logikę biznesową ani zależności między rekordami. Przed wdrożeniem na produkcję kod i tak trzeba przetestować na prawdziwym API — mocki jedynie przyspieszają wczesne etapy programowania.
Realistyczne edge case'y w mockach
Dobry generator mocków celowo zawiera „niewygodne" wartości — bardzo długie imiona, puste ciągi, polskie znaki diakrytyczne (ą, ć, ę, ł, ń, ó, ś, ź, ż) obok czystego ASCII, zerowe lub ujemne liczby, daty na granicy zakresu. To właśnie takie wartości najczęściej psują wygląd lub logikę, którą programista testował jedynie na „wygodnych" danych typu "John Doe" — dlatego losowość mocków jest bardziej użyteczna niż ten sam przykład testowy za każdym razem.