استراتژی تست: واحد، یکپارچه و E2E با Playwright بدون هرم وارونه
چطور پوشش معنادار بسازید، چه چیزی را واحد تست کنید، و کدام مسیرها شایستهٔ Playwright در CI هستند.
علی مرتضوی
بنیانگذار پارادایس کد
هدف تست اعتماد قابل تکرار است نه درصد پوشش
پوشش خط بهتنهایی کیفیت نمیسازد. سؤال درست این است: اگر این مسیر بشکند، آیا قبل از کاربر میفهمیم؟ هرم تست یعنی منطق خالص را ارزان و سریع واحدی بگیرید، مرزها را با تست یکپارچه محکم کنید، و E2E را برای سناریوهای حیاتی رزرو کنید.
تیمهایی که همهچیز را E2E میکنند، CI کند و شکننده میسازند؛ تیمهایی که فقط واحد مینویسند، یکپارچگی واقعی را از دست میدهند.
تست واحد برای منطق تصمیم
قیمتگذاری، مجوز، اعتبارسنجی فرم، تبدیل تاریخ/پول، و reducerها بهترین اهداف واحدند. آنها را از I/O جدا کنید تا بدون مرورگر و دیتابیس در میلیثانیه اجرا شوند. اگر برای تست واحد باید نصف Nest را mock کنید، مرز ماژول اشتباه است.
نام تست را با رفتار کسبوکار بنویسید نه با نام تابع. فردا وقتی کد عوض شد، رفتار باید همان بماند.
یکپارچگی در مرزهای واقعی
برای API، تستهایی که HTTP واقعی به اپ در حال اجرا یا ماژول Nest میزنند و دیتابیس تست را لمس میکنند، باگهای wiring را میگیرند. قرارداد OpenAPI را اینجا validate کنید. برای فرانت، تست کامپوننت با نقشهای دسترسیپذیر (Testing Library) تعاملات را بدون هزینه E2E کامل پوشش میدهد.
دادهٔ تست را قابل ساخت و پاکسازی نگه دارید. وابستگی به snapshot دیتابیس دستی، تست را در ماه دوم میکشد.
Playwright برای مسیرهای پول و اعتماد
E2E را روی ثبتنام، ورود، checkout، انتشار محتوا، و مسیرهای RBAC حساس متمرکز کنید—نه روی هر دکمه. هر سناریو باید از دید کاربر نوشته شود: «خریدار میتواند سفارش را تمام کند» نه «کامپوننت Modal باز میشود».
پایداری مهمتر از تعداد است: انتظار روی نقش/متن پایدار، نه روی timeoutهای تصادفی؛ جداسازی داده بین تستها؛ و رتری فقط برای flaky شناختهشدهٔ محیطی نه برای پنهان کردن باگ.
داده، محیط و اسرار در CI
محیط E2E باید نزدیک پروداکشن باشد اما با seed کنترلشده. سرویسهای بیرونی را mock یا sandbox کنید تا صورتحساب واقعی و نرخ شکننده ایجاد نشود. اسرار تست را از اسرار پروداکشن جدا نگه دارید.
آرتیفکت شکست—trace، ویدئو، اسکرینشات—را در CI ذخیره کنید. بدون آن، دیباگ E2E حدس است.
مالکیت و سیگنال در تیم
هر تست flaky یک بدهی است؛ یا درستش کنید یا قرنطینه و مالک تعیین کنید. تست قرمز بیصاحب فرهنگ نادیدهگرفتن را میسازد. در PR، تست مرتبط با تغییر اجباری باشد—نه قول «بعداً مینویسیم».
هر ماه یک بازبینی: کدام E2E ارزش دارد، کدام واحد کم است، کدام مسیر پروداکشن بدون تور ایمنی است. استراتژی تست محصول زنده است.
سؤالات متداول
چند درصد پوشش خوب است؟
عدد جادویی وجود ندارد. روی ماژولهای پرریسک هدف بگذارید و با باگهای فرارشده اندازه بگیرید، نه با vanity metric.
آیا snapshot UI مفید است؟
برای قرارداد بصری محدود بله؛ برای درخت DOM بزرگ زود شکننده میشود. ترجیح با assertion رفتاری است.
E2E را روی PR اجرا کنیم یا شبانه؟
دودِ مسیرهای حیاتی روی PR؛ سوئیت گستردهتر شبانه یا روی main. تعادل سرعت بازخورد و عمق پوشش مهم است.
Playwright بهتر است یا Cypress؟
هر دو قابمند؛ Playwright در چندمرورگر/چندکانتکست و CI مدرن اغلب سادهتر است. انتخاب را با مهارت تیم و پایداری سوئیت بسنجید.
دانش و مقالات
نیاز به اجرای همین مفاهیم در محصولتان دارید؟
پارادایس کد از مشاوره تا پیادهسازی کامل کنار شماست.