Q: Fixture-lər və beforeEach — hansını nə vaxt seçirsən?

Qaydam sadədir: bir şey yaradırsansa və onu geri təmizləmək lazımdırsa — fixture; sadəcə eyni səhifəyə keçirsənsə — hook. Fixture-in üç konkret üstünlüyü: (1) lazımi qədər işə düşür — testin arqumentində yoxdursa, ümumiyyətlə icra olunmur; beforeEach isə blokdakı hər testə tətbiq olunur, hətta ona ehtiyacı olmayanlara da (10 testin 2-si üçün user yaradırsansa, bu, boş yerə 8 user deməkdir); (2) tiplidir — yaradılan obyekt testə arqument kimi gəlir; beforeEach-də isə paylaşılan dəyişən lazım olur ki, bu da paralel icrada tələ ola bilər; (3) kompozisiya olunur — order fixture-i user fixture-indən asılı ola bilər, Playwright sıranı özü həll edir. Amma dogmatik deyiləm: beforeEach(() => page.goto('/')) üçün fixture yazmaq lazımsız mürəkkəblikdir. Cavabın bu hissəsi vacibdir — interview-da "həmişə X" tipli cavablar zəif, kontekstə görə seçim edən cavablar güclü sayılır.

Question 1

500 testlik suite-i necə təşkil edərdin?

Accepted Answer

Dörd ölçüdə danışıram, çünki sual həm struktur, həm icra, həm proses haqqındadır. Fayl strukturu: feature üzrə qovluqlar (tests/checkout/, tests/auth/), fayl adı feature-ə uyğun, describe blokları ilə məntiqi qruplar. Tag sistemi: @smoke (kritik minimum, PR-da, <10 dəq), @regression (tam əhatə, nightly), @slow, @flaky (quarantine, ayrıca işləyir və heç kimi bloklamır). Tag-lar konvensiya kimi sənədləşdirilir, yoxsa hərə öz tag-ını uydurur. İcra strategiyası: PR-da smoke; merge-dən sonra genişlənmiş dəst; nightly tam regression + sharding (4-8 maşın). Testlər tam müstəqil olduğu üçün bu mümkündür — serial mode yalnız məcburi hallarda. Sahiblik və gigiyena: hər feature qovluğunun sahibi var; skip/fixme mütləq ticket linki ilə; kvartalda bir dəfə "ölü test" təmizliyi — heç vaxt sınmayan və heç nə tapmayan testlər namizəddir. Son vurğu: 500 testin əsas problemi texniki deyil, inam problemidir. Suite yavaş və flaky olsa, insanlar ona baxmır — buna görə sürət və flaky rate mənim üçün birinci dərəcəli metrikalardır.

Question 2

Fixture-lər və beforeEach — hansını nə vaxt seçirsən?

Accepted Answer

Qaydam sadədir: bir şey yaradırsansa və onu geri təmizləmək lazımdırsa — fixture; sadəcə eyni səhifəyə keçirsənsə — hook. Fixture-in üç konkret üstünlüyü: (1) lazımi qədər işə düşür — testin arqumentində yoxdursa, ümumiyyətlə icra olunmur; beforeEach isə blokdakı hər testə tətbiq olunur, hətta ona ehtiyacı olmayanlara da (10 testin 2-si üçün user yaradırsansa, bu, boş yerə 8 user deməkdir); (2) tiplidir — yaradılan obyekt testə arqument kimi gəlir; beforeEach-də isə paylaşılan dəyişən lazım olur ki, bu da paralel icrada tələ ola bilər; (3) kompozisiya olunur — order fixture-i user fixture-indən asılı ola bilər, Playwright sıranı özü həll edir. Amma dogmatik deyiləm: beforeEach(() => page.goto('/')) üçün fixture yazmaq lazımsız mürəkkəblikdir. Cavabın bu hissəsi vacibdir — interview-da "həmişə X" tipli cavablar zəif, kontekstə görə seçim edən cavablar güclü sayılır.

Question 3

Komandada tag konvensiyasını necə qurursan və pozulmamasını necə təmin edirsən?

Accepted Answer

Əvvəlcə tag-ların sayını məhdud saxlayıram — 5-dən çox tag olan sistem bir ilə istifadəolunmaz olur, çünki heç kim hansını seçəcəyini bilmir. Mənim dəstim: @smoke, @regression, @slow, @flaky, @wip. Hər tag üçün bir cümləlik tərif və seçim meyarı yazılır: məsələn, "@smoke — sınarsa release bloklanmalıdırsa". Tərifsiz tag subyektiv olur və hamı öz testini smoke sayır (klassik nəticə: 200 testlik "smoke"). Pozulmamasının təminatı avtomatlaşdırmadır, xatırlatma deyil: (1) tag-sız test qalmaması üçün sadə bir yoxlama script-i CI-da; (2) @smoke dəstinin müddətinə limit — 10 dəqiqəni keçəndə pipeline xəbərdarlıq verir və komanda ya optimizasiya edir, ya testi regression-a köçürür; (3) PR checklist-də bir sətir. Əlavə edərdim ki, konvensiyanı bir dəfə qurub unutmaq olmaz — kvartalda bir dəfə smoke dəstinə baxıram: real insidentlərdən sonra bəzi testlər smoke-a qaldırılmalı, bəziləri isə artıq dəyər vermədiyi üçün çıxarılmalı olur.

Annotasiya	Mənası	Nə vaxt istifadə et
test.skip(reason)	Test işlədilmir	Şərt ödənmir (məs. feature bu mühitdə yoxdur) — səbəb yazılmalıdır
test.fixme(reason)	Test sınıqdır, düzəliş gözlənilir	Quarantine — ticket linki ilə birlikdə
test.fail()	Fail GÖZLƏNİLİR; keçərsə xəbərdarlıq verir	Məlum, hələ düzəlməmiş product bug — düzələn kimi xəbər tutursan
test.slow()	Timeout 3x artır	Obyektiv uzun axın (hesabat generasiyası, batch job)
test.only()	Yalnız bu test işləyir	Lokal debugging; main-ə düşməsi lint ilə bloklanmalıdır

Testlərin təşkili: tag-lar, hook-lar, addımlar, annotasiyalar

📚 Mənbələr və sənədlər