Test datası strategiyaları

Test datası avtomatlaşdırmada flakiness-in birinci mənbəyidir. Əsas qayda: hər test öz datasını özü yaradır, özü təmizləyir və başqa testin datasına toxunmur.

Dörd yanaşma və onların yeri:

• Statik fixture fayl (JSON) — yalnız read-only referans data üçün (ölkələr, valyutalar). Dəyişən data üçün pisdir: paralel testlər eyni sətri dəyişib bir-birini sındırır.
• Shared seed data — mühitə əvvəlcədən yüklənmiş data. Yalnız READ-ONLY istifadə oluna bilər; kim isə onu dəyişdirsə, səbəbi tapılmayan fail-lər başlayır.
• Factory + API seeding (əsas yanaşma) — testin ehtiyacı olan obyekt factory ilə qurulur, backend-də API ilə yaradılır, teardown-da silinir.
• UI ilə yaratma — yalnız yaratma prosesinin ÖZÜ test olunanda. Hazırlıq üçün istifadə etmək yavaşdır və aidiyyatı olmayan testləri sındırır.

Factory pattern — default dəyərləri olan, override qəbul edən data qurucu funksiya:

• buildUser() → tam etibarlı default user
• buildUser({ role: 'admin' }) → yalnız fərqi göstərirsən

Bu, testin oxunaqlığı üçün kritikdir: spec-də yalnız ssenariyə aid olan sahələr görünür, qalan 15 sahə gözdən yayınır. "Bu test niyə admin haqqındadır?" sualının cavabı bir sətirdə görünür.

Paralel icra üçün unikallıq — ən çox rast gəlinən problem. İki worker eyni anda [email protected] ilə user yaratmağa çalışır → biri 409 alır → təsadüfi fail. Həll: hər dəyərdə unikal komponent — user-${randomUUID()}@test.local. Yalnız timestamp KİFAYƏT DEYİL: eyni millisaniyədə iki worker toqquşa bilər; UUID və ya worker-index + timestamp birləşməsi daha etibarlıdır.

Təmizləmə (cleanup) fixture teardown-da olmalıdır — afterEach-də deyil, çünki fixture teardown test fail olanda da işləyir. Əlavə müdafiə xətti: nightly cleanup job köhnə test datasını silir (fail olan run-lar həmişə zibil qoyur).