Playwright یا Cypress؛ تست سریع‌تر ممکن است کد و CI بیشتری بخواهد

برای تیمی که آزمون سرتاسری آن به چند تب، نشست‌های مستقل یا مرورگرهای مختلف می‌رسد، Playwright معمولاً گزینهٔ قوی‌تری برای ارزیابی است. برای پروژهٔ کوچک با مجموعهٔ پایدار Cypress، سرعت بیشتر یک آزمون به‌تنهایی دلیل کافی برای بازنویسی نیست؛ هزینهٔ کد، دادهٔ آزمون و اجرای CI باید کنار زمان کل مجموعه سنجیده شود.

معیار اصلی، زمان کل خط لولهٔ CI و هزینهٔ حفظ سناریوهای واقعی است: چندمرورگری، چندتب و نشست‌های مستقل. هرکدام فشار متفاوتی بر کد و CI وارد می‌کند؛ یک آزمون نمونه جای این ارزیابی را نمی‌گیرد.

سرعت بیشتر در پژوهش با چه مقدار کد همراه بود؟

در پژوهش تجربی روی یک برنامهٔ Angular، آزمون ثبت‌نام با Playwright به ۳۳ خط کد بدون توضیح و با Cypress به ۴۴ خط نیاز داشت؛ در سناریوی ثبت گزارش توسط کاربر و بررسی آن توسط مدیر، نسبت برعکس شد: ۴۳ خط برای Playwright در برابر ۳۵ خط برای Cypress. سناریوی اخیر در پیاده‌سازی پژوهش با دو browser context در Playwright نوشته شد. با وجود کد بیشتر، میانگین زمان آن در نمودار پژوهش ۱۵٫۱۴ ثانیه برای Playwright و ۲۵٫۹۳ ثانیه برای Cypress بود.

Playwright در همهٔ سناریوهای اندازه‌گیری‌شده سریع‌تر اجرا شد. آزمون‌ها روی همان برنامه، با مرورگرهای مشخص و در حالت headless اجرا شدند و دادهٔ برنامه پیش از هر اجرا بازنشانی می‌شد. بنابراین زمان‌های ثبت‌شده، زمان یک خط لولهٔ واقعی با نصب وابستگی، ساخت برنامه، آماده‌سازی پایگاه داده و بار هم‌زمان سایر کارهای CI نیستند. نتیجهٔ قابل انتقال، جهت یک مبادله است: سناریویی با نشست‌های جدا می‌تواند سریع‌تر تمام شود و در عین حال کد بیشتری بخواهد.

شمار خطوط نیز جانشین کامل هزینهٔ نگه‌داری نیست. اگر کوتاه شدن فایل از تابع‌های کمکی مشترک و رفتار پنهان آن‌ها بیاید، پیدا کردن علت شکست ممکن است سخت‌تر شود؛ اگر چند خط اضافه مرز نشست‌های کاربر و مدیر را آشکار کند، می‌تواند فهم آزمون را آسان‌تر کند. برای مقایسهٔ دو پیاده‌سازی، همان مسیر محصول و همان تعریف موفقیت را نگه دارید و علاوه بر طول کد، وابستگی به داده‌های آماده‌شده و زمان عیب‌یابی را بسنجید.

پوشش چندمرورگری کجا هزینه پیدا می‌کند؟

راهنمای مرورگرهای Cypress خانوادهٔ Chrome و Firefox را در کنار WebKit فهرست می‌کند، اما پشتیبانی WebKit را آزمایشی می‌داند. برای اجرای آن باید گزینهٔ experimentalWebKitSupport فعال و بستهٔ playwright-webkit نصب شود؛ محیط Linux نیز وابستگی‌های اضافی می‌خواهد. مرورگر هدف باید در محیط محلی یا CI در دسترس باشد و نسخهٔ آن در اجرای مداوم کنترل شود.

اگر بخشی از کاربران با موتور WebKit کار می‌کنند، صرف دیدن نام آن در فهرست پشتیبانی کافی نیست. اهمیت وضعیت آزمایشی به این بستگی دارد که شکست احتمالی در آن موتور مانع انتشار محصول است یا فقط هشدار تکمیلی. Playwright و Cypress را با همان مسیر حساس و همان محیط اجرا مقایسه کنید؛ آزمونی که فقط در مرورگر پیش‌فرض موفق می‌شود، پاسخ پرسش چندمرورگری را نمی‌دهد.

اجرای تمام مسیرها در تمام مرورگرها نیز هزینهٔ محاسباتی و زمان انتظار را بالا می‌برد. برای یک مجموعهٔ بزرگ، می‌توان مسیرهای بحرانی را در همهٔ موتورهای هدف و بخش‌های کم‌خطرتر را در مرورگر اصلی اجرا کرد. این یک انتخاب دربارهٔ پوشش آزمون است، نه ویژگی ذاتی هیچ‌یک از چارچوب‌ها؛ معیار، خطر واقعی محصول و ظرفیت CI تیم است.

چند تب و چند کاربر یک مسئله نیستند

در مستندات page در Playwright، هر browser context می‌تواند چند page داشته باشد و آزمون می‌تواند منتظر باز شدن تب تازه بماند و سپس با آن تعامل کند. این مدل وقتی مهم است که مسیر کاربر از تب اصلی به صفحهٔ دیگری می‌رود و نتیجه باید در هر دو صفحه بررسی شود. در چنین سناریویی، تب تازه صرفاً مقصد یک پیوند نیست؛ بخشی از رفتار مورد آزمون است.

دو تب در یک context با دو context مستقل تفاوت دارند. اولی برای جابه‌جایی میان صفحه‌های یک نشست مناسب است؛ دومی برای نقش‌هایی مانند کاربر و مدیر که باید وضعیت مرورگر جدا داشته باشند. در جریان ثبت و رسیدگی به گزارشِ مثال بالا نیز دو نشست جدا به کار رفت. پیش از تخمین هزینهٔ مهاجرت، باید روشن باشد کدام آزمون‌ها واقعاً به کنترل هم‌زمان صفحه‌ها یا نشست‌های جدا نیاز دارند.

اگر فقط مقصد پیوند اهمیت دارد، آزمون نشانی یا رفتار ناوبری ممکن است بدون ادارهٔ تب دوم کافی باشد. اما وقتی تأیید در تب دیگر، بازگشت به تب نخست یا تعامل دو نقش شرط پذیرش است، شکستن جریان به آزمون‌های تک‌صفحه‌ای بخشی از رابطهٔ علت و نتیجه را حذف می‌کند. در این نقطه قابلیت کنترل مستقیم page در Playwright ارزش عملی پیدا می‌کند و می‌توان آن را با هزینهٔ بازنویسی همان مسیرها سنجید.

موازی‌سازی چه چیزی را در CI عوض می‌کند؟

مستندات موازی‌سازی Playwright می‌گوید فایل‌های آزمون به‌طور پیش‌فرض در workerهای مستقل و هم‌زمان اجرا می‌شوند؛ آزمون‌های داخل هر فایل در حالت عادی ترتیبی‌اند. شمار workerها قابل تنظیم است و هر worker مرورگر خودش را راه می‌اندازد. برای پخش مجموعه میان ماشین‌های CI، Playwright امکان تقسیم آزمون‌ها به بخش‌های مجزا را هم دارد، اما این کار به تعریف اجرای بخش‌ها در خط لوله نیاز دارد.

جداسازی مرورگر، دادهٔ مشترک سمت سرور را جدا نمی‌کند. اگر دو آزمون یک حساب یا رکورد پایگاه داده را تغییر دهند، اجرای موازی می‌تواند به شکست وابسته به ترتیب برسد. ساخت دادهٔ مستقل برای هر آزمون یا worker و پاک‌سازی قابل اعتماد آن، بخشی از هزینهٔ واقعی سرعت است. زیاد کردن worker وقتی برنامهٔ تحت آزمون یا پایگاه داده زیر بار هم‌زمان کند می‌شود، الزاماً زمان کل CI را کم نمی‌کند.

در موازی‌سازی Cypress Cloud، اجراهای ثبت‌شده بر اساس فایل آزمون میان ماشین‌های آمادهٔ CI تقسیم می‌شوند. این مسیر به ثبت اجرا، ماشین‌های موازی و چیدمان مناسب فایل‌ها نیاز دارد؛ فایل‌های بسیار نامتوازن ممکن است باعث شوند بخشی از ماشین‌ها زودتر بیکار بمانند. مقایسهٔ آن با workerهای Playwright باید در سطح یکسان انجام شود: زمان کل کار CI، منابع مصرف‌شده و پایداری داده، نه فقط مدت اجرای یک فایل.

ماتریس انتخاب برای وضعیت‌های رایج

• پروژهٔ کوچک با Cypress پایدار: اگر مسیرها عمدتاً تک‌تب‌اند، مرورگرهای لازم پوشش داده می‌شوند و زمان CI قابل قبول است، حفظ مجموعهٔ فعلی معمولاً از مهاجرت کامل کم‌هزینه‌تر است. برای پروژهٔ تازه، یک مسیر واقعی را با هر دو ابزار پیاده کنید.
• مجموعهٔ بزرگ با CI موازی: Playwright برای اجرای پیش‌فرض فایل‌ها در workerها نقطهٔ شروع روشنی دارد. اگر Cypress Cloud و ماشین‌های موازی از قبل برقرارند، سود جابه‌جایی باید پس از حساب کردن زیرساخت موجود سنجیده شود.
• جریان چندتب یا چند نقش: کنترل مستقیم pageها و contextها در Playwright مزیت روشن‌تری دارد. ارزش آن به شمار مسیرهایی بستگی دارد که واقعاً باید دو صفحه یا دو نشست را در یک آزمون هماهنگ کنند.
• WebKit در مسیر انتشار: وضعیت آزمایشی WebKit در Cypress و وابستگی‌های نصب را وارد برآورد کنید. سپس رفتار مسیرهای حساس را روی موتور و سیستم‌عامل هدف خود بسنجید.

هزینهٔ مهاجرت را با چه چیزی بسنجیم؟

تبدیل دستورهای Cypress به Playwright فقط بخشی از کار است. ورود کاربران آزمایشی، آماده‌سازی و پاک‌سازی داده، روش‌های یافتن عناصر صفحه، شبیه‌سازی شبکه، گزارش شکست و تنظیمات CI نیز باید با رفتار چارچوب تازه هماهنگ شوند. مجموعه‌ای که تابع‌های کمکی زیادی دارد ممکن است با وجود شمار کم فایل‌ها، مهاجرت دشواری داشته باشد؛ چون قراردادهای پنهان میان آزمون‌ها باید دوباره روشن شوند.

ارزیابی محدود را روی مسیرهایی انجام دهید که نتیجهٔ انتخاب را تغییر می‌دهند: یک جریان ساده، یک جریان چندتب یا چندنقش و یک مسیر حساس به مرورگر. برای هر پیاده‌سازی، زمان کل خط لوله از آغاز اجرای CI تا گزارش نهایی، مقدار کد آزمون و تابع‌های کمکی، مصرف منابع و شکست‌های قابل بازتولید را با تعریف یکسان ثبت کنید. این‌ها معیارهای تصمیم تیم هستند و عددهای پژوهش Angular را به محصول دیگر تعمیم نمی‌دهند.

بیشتر بخوانید:

• Playwright یا Cypress؛ سرعت بدون جداسازی آزمون‌ها دوام نمی‌آورد
• SPAC یا IPO سنتی؛ مسیر کوتاه‌تر می‌تواند رقیق‌سازی بیشتری بیاورد
• SQLite یا PostgreSQL؛ یک نویسنده سریع است، ۱۶ نویسنده برنده را عوض می‌کنند