Test kodunda tez-tez işlənən JS pattern-ləri
Avtomatlaşdırma layihələrində eyni bir neçə məsələ təkrar-təkrar qarşıya çıxır. Onların hazır həlli var — və interview-də bu pattern-ləri koda çevirə bilmək middle səviyyəni junior-dan ayıran əsas göstəricidir:
- Retry wrapper — qeyri-sabit infrastruktur əməliyyatını bir neçə dəfə cəhd etmək
- Polling / waitFor — UI-da görünməyən asinxron nəticəni gözləmək
- Data builder (factory) — hər testə təzə və unikal test datası qurmaq
- Utility kompozisiyası — kiçik, təmiz funksiyaları birləşdirmək
Bunların hamısının altında bir prinsip dayanır: testlər bir-birindən asılı olmamalıdır. Paylaşılan dəyişən state, sıra fərziyyəsi və "əvvəlki testin yaratdığı data" — flakiness-in ən böyük mənbəyidir.
Retry və polling eyni şey deyil — interview-də bu fərqi bilmək yaxşı təsir bağışlayır.
Retry — əməliyyatı yenidən icra etmək. Uğursuz cəhd real bir hərəkət idi (POST sorğusu, resurs yaradılması) və onu təkrarlayırsan. Gözləmə müddəti hər cəhddə artırılır — exponential backoff (300ms → 600ms → 1200ms), üstünə kiçik təsadüfi əlavə (jitter) qoyulur ki, paralel işləyən worker-lər eyni anda təkrar cəhd edib serveri yükləməsin.
Polling — vəziyyəti təkrar-təkrar yoxlamaq. Heç nə yenidən icra olunmur; sadəcə "artıq hazırdırmı?" sualı sabit intervalla verilir, ta ki şərt ödənsin və ya timeout bitsin. Növbədəki mesajın işlənməsi, e-poçtun gəlməsi, invoice-in yaradılması — hamısı polling məsələsidir.
Hər ikisi üçün eyni tələb: timeout məcburidir, xəta mesajı isə nəyi gözlədiyini deməlidir. Timed out after 30000ms faydasızdır; Timed out after 30000ms waiting for invoice of order 1042 (last status: pending) isə problemi bir baxışda göstərir.
| Pattern | Hansı problemi həll edir | Riski |
|---|---|---|
| Retry wrapper (backoff ilə) | qeyri-sabit infrastruktur: şəbəkə, 502, test data servisi | məhsulun real bug-ını gizlədə bilər |
| Polling / waitFor | UI-da görünməyən asinxron nəticə (queue, e-poçt, invoice) | uzun timeout bütün suite-i yavaşladır |
| Data builder / factory | hər testə təzə, unikal və izolyasiya olunmuş data | cleanup unudulsa baza zibillənir |
| Utility kompozisiyası | kiçik funksiyalardan mürəkkəb ssenari qurmaq | həddindən artıq abstraksiya oxunaqlılığı azaldır |
| Fixture (framework səviyyəsində) | setup və zəmanətli teardown | gizli asılılıqlar testi oxunmaz edir |
Retry-ın ən təhlükəli istifadəsi — assertion-ları təkrarlamaqdır. Əməliyyatı yenidən cəhd etmək legitimdir; "assertion düşdü, bir də yoxlayaq" isə real reqressiyanı statistik olaraq gizlədir. Qayda: retry yalnız infrastruktur əməliyyatlarına (şəbəkə, resurs yaradılması, xarici servis) tətbiq olunur, məhsulun davranışına yox.
Eyni məntiq framework səviyyəsindəki retries parametrinə də aiddir: o, CI-da faydalıdır, amma retry sayı artırıla-artırıla gedirsə, bu, suite-in xəstə olmasının göstəricisidir. Sağlam yanaşma — retry-ları ölçmək (neçə test yalnız ikinci cəhddə keçir) və həmin testləri araşdırmaq.
İnterview-də retry haqqında soruşulanda cavabına mütləq bu cümləni əlavə et: "Retry simptomu maskalayır; ona görə hər retry qeydə alınmalı və səbəbi araşdırılmalıdır."
📚 Mənbələr və sənədlər
- Playwright: ən yaxşı praktikalarrəsmiplaywright.dev