رکورد تصمیم معماری: چارچوب خودکارسازی مرورگر برای آزمون E2E (Playwright در برابر Selenium)

1. زمینه

در حال انتخاب یک چارچوب خودکارسازی مرورگر برای خط‌لولهٔ آزمون سرتاسری (E2E) خود هستیم. این چارچوب بخش جدایی‌ناپذیر فرایندهای CI/CD ما خواهد بود و آزمون‌هایی را اجرا می‌کند که تعامل‌های واقعی کاربران را روی پلتفرم ما شبیه‌سازی می‌کنند. به‌طور مشخص، آزمون‌ها سناریوهایی مانند ثبت‌نام/ورود کاربر، بارگذاری فایل، تعامل با داشبوردها و دانلود گزارش‌ها را پوشش خواهند داد.

به‌عنوان یک استارتاپ، تمرکز ما بر توسعهٔ چابک است و نیاز به تکرار و تکامل سریع داریم. تیم ما عمدتاً با TypeScript و Python کار می‌کند و توانایی نوشتن آزمون به این زبان‌ها ضروری است. علاوه بر این، پلتفرم شامل نمودارها و داشبوردهای تعاملی است، که ایجاب می‌کند ابزار خودکارسازی از رابط‌های کاربری غنی و پویا به‌خوبی پشتیبانی کند.

دو رقیب این کار Playwright و Selenium هستند که هر یک نقاط قوت و مصالحه‌های خود را دارند. باید این چارچوب‌ها را بر پایهٔ ویژگی‌ها و نیازمندی‌های زیر ارزیابی کنیم.

2. گزینه‌های بررسی‌شده

• Playwright (از Microsoft)
• Selenium (از Selenium Project)

3. عوامل تصمیم

عواملی که بر تصمیم ما اثر می‌گذارند به شرح زیرند:

1. توسعهٔ چابک: ابزار انتخاب‌شده باید چرخه‌های توسعهٔ سریع و انعطاف‌پذیر را ممکن کند.
2. پشتیبانی از زبان: تیم ما به پشتیبانی هم از TypeScript و هم از Python نیاز دارد.
3. آزمون UI تعاملی: توانایی آزمودن قابل‌اعتماد نمودارهای تعاملی، داشبوردها و عناصر پویا ضروری است.
4. سرعت زمان اجرا: هرچند دغدغهٔ اصلی نیست، کارایی در خط‌لوله‌های CI/CD ملاحظه‌ای است.
5. مقیاس‌پذیری: در آیندهٔ نزدیک برای مقیاس عظیم برنامه‌ریزی نمی‌کنیم، اما می‌خواهیم اطمینان یابیم راه‌حل می‌تواند رشد آینده را تاب آورد.
6. سازگاری با نسخه‌های قدیمی: سیستم‌های قدیمی و سازگاری با مرورگرهای قدیمی‌تر در حال حاضر برای پروژهٔ ما حیاتی نیستند.
7. آزمون موبایل: هرچند تمرکز فوری نیست، چارچوب باید بتواند ویژگی‌های واکنش‌گرا به موبایل را آزمایش کند یا برای چنین موارد استفاده‌ای قابل گسترش باشد.
8. آزمون چندمانیتوره: پشتیبانی از پیکربندی‌های چندمانیتوره نیازمندی ثانویه است، به‌ویژه اگر روزی به آزمودن گردش‌های کار پیچیده‌تر کاربران گسترش یابیم.
9. آزمون بارگذاری فایل: چارچوب باید بارگذاری فایل را کارآمد مدیریت کند، که نیازمندی اصلی نیازهای آزمون ماست.

4. معیارهای ارزیابی

• سهولت استفاده: نوشتن و نگهداری آزمون‌ها چقدر آسان است؟
• پشتیبانی از زبان: آیا چارچوب از TypeScript و Python، دو زبانی که تیم ما بیش از همه استفاده می‌کند، پشتیبانی می‌کند؟
• آزمون UI تعاملی: چارچوب رابط‌های کاربری پیچیده و تعاملی مانند نمودارها، بارگذاری فایل و داده‌های پویا را چقدر خوب مدیریت می‌کند؟
• ادغام CI/CD: چارچوب چقدر خوب در ابزارها و سرویس‌های رایج CI/CD ادغام می‌شود؟
• پشتیبانی میان‌مرورگری: کدام مرورگرها پشتیبانی می‌شوند و چقدر خوب عمل می‌کنند؟
• کارایی و سرعت: آزمون‌ها چقدر سریع اجرا می‌شوند، به‌ویژه در خط‌لولهٔ CI/CD؟
• مقیاس‌پذیری: اگر آزمون‌های بیشتر یا سناریوهای پیچیده‌تری اضافه شود، چارچوب چقدر خوب می‌تواند مقیاس یابد؟
• جامعه و اکوسیستم: جامعهٔ چارچوب چقدر فعال است؟ آیا ادغام‌ها و پسوندهای فراوانی در دسترس است؟

5. ملاحظات

5.1 Playwright

مزایا:

1. API هوشمندتر برای بارگذاری فایل محلی: API مربوط به Playwright برای تعامل با فایل‌های محلی و انجام بارگذاری فایل ساده‌تر و شهودی‌تر است. این امر پیاده‌سازی و نگهداری آزمون بارگذاری فایل را آسان‌تر می‌کند.
2. نحو و تولید کد: Playwright نحو کوتاه‌تر و موجزتری دارد. این به کد استاندارد (boilerplate) کمتر می‌انجامد که نگهداری‌پذیری و کارایی توسعه‌دهنده را بهبود می‌دهد. علاوه بر این، این نحو کوتاه‌تر کیفیت تولید کد OpenAI را بهبود می‌دهد و تولید خودکار اسکریپت‌های آزمون را آسان‌تر می‌کند.
3. آزمون UI تعاملی: Playwright در آزمودن برنامه‌های وب پویا و تعاملی، مانند آن‌هایی با نمودارهای غنی، تعامل‌های پیچیدهٔ کاربر و به‌روزرسانی‌های بی‌درنگ، برتری دارد. WebSockets، WebRTC، shadow DOMها و سایر فناوری‌های وب مدرن را بسیار مؤثر مدیریت می‌کند.
4. پشتیبانی میان‌مرورگری: Playwright از Chromium، WebKit و Firefox پشتیبانی می‌کند. کارایی یکدستی در این مرورگرها دارد که باید بیشتر نیازهای آزمون ما را پوشش دهد.
5. ادغام CI/CD: Playwright به‌طور یکپارچه با پلتفرم‌های مدرن CI/CD (GitHub Actions، Jenkins و غیره) ادغام می‌شود. می‌تواند آزمون‌ها را به‌صورت موازی در مرورگرهای مختلف اجرا کند، زمان اجرای آزمون را بهینه می‌کند و برای توسعهٔ سریع مناسب است.
6. سریع و قابل‌اعتماد: Playwright عموماً از Selenium سریع‌تر است، به‌ویژه در حالت headless، و هنگام مواجهه با عناصر وب ناهمگام مقاوم‌تر است.

معایب:

1. آزمون محدود موبایل: هرچند Playwright از شبیه‌سازی موبایل برای مرورگرها پشتیبانی می‌کند، قابلیت‌های آزمون موبایل بومی مانند ادغام Selenium با Appium برای آزمون واقعی موبایل را ندارد.
2. اکوسیستم کوچک‌تر: Playwright هنوز جدیدتر و کمتر جاافتاده از Selenium است. هرچند جامعه‌ای به‌سرعت رو به رشد و مستندات خوب دارد، ممکن است هنوز اکوسیستم وسیع افزونه‌ها و ادغام‌هایی را که Selenium ارائه می‌دهد نداشته باشد.
3. پشتیبانی محدود از مرورگر: هرچند Playwright مرورگرهای مدرن اصلی (Chrome، Safari، Firefox) را پوشش می‌دهد، پشتیبانی آن از مرورگرهای قدیمی (مثلاً Internet Explorer) به اندازهٔ Selenium قوی نیست.

5.2 Selenium

مزایا:

1. سابقهٔ طولانی‌تر و بلوغ: Selenium مدت‌ها وجود دارد و سابقهٔ اثبات‌شده‌ای دارد. در بسیاری از تیم‌ها و صنایع به‌طور گسترده استفاده می‌شود که به اکوسیستم وسیعی از افزونه‌ها، ادغام‌ها و منابع انجامیده است.
2. پشتیبانی میان‌مرورگری و میان‌پلتفرمی: Selenium از طیف وسیعی از مرورگرها و نسخه‌ها، از جمله Internet Explorer، پشتیبانی می‌کند و همچنین می‌تواند با ابزارهای گوناگونی مانند Docker، Selenium Grid و سرویس‌های ابری برای آزمون توزیع‌شده ادغام شود.
3. آزمون موبایل: Selenium، از طریق ادغامش با Appium، برای آزمون موبایل، شامل برنامه‌های Android و iOS، بسیار مقاوم‌تر است. این آن را انتخاب بهتری برای پروژه‌هایی با تمرکز موبایل-اول یا موبایل-سنگین می‌کند.
4. آزمون چندمانیتوره: Selenium برای سناریوهای شامل چند مانیتور یا تعامل‌های پیچیدهٔ چندپنجره‌ای پشتیبانی بهتری ارائه می‌دهد.

معایب:

1. پیچیدگی: API مربوط به Selenium پرگوتر و صریح‌تر است. هرچند در برخی موارد می‌تواند مزیت باشد، به معنای کد بیشتر برای نوشتن و نگهداری است که ممکن است چابکی توسعه‌دهنده را کاهش دهد — که در محیط استارتاپ به‌ویژه مهم است.
2. کارایی: Selenium عموماً کندتر از Playwright اجرا می‌شود، به‌ویژه در حالت headless. این می‌تواند بر خط‌لوله‌های CI/CD تأثیر بگذارد، به‌ویژه با افزایش تعداد آزمون‌ها.
3. آزمون UI تعاملی: هنگام آزمودن UIهای وب مدرن و تعاملی، به‌ویژه با نمودارها و به‌روزرسانی‌های دادهٔ بی‌درنگ، Selenium به روانی Playwright نیست. برای تعامل قابل‌اعتماد با محتوای پویا به راه‌اندازی و مدیریت بیشتری نیاز دارد.

6. خلاصهٔ مقایسه

ویژگی	Playwright	Selenium
سهولت استفاده	نحو کوتاه‌تر، برای UIهای مدرن شهودی‌تر	صریح‌تر، boilerplate بیشتری لازم دارد
پشتیبانی از زبان	TypeScript، Python، JavaScript	TypeScript، Python، Java، Ruby، C#
آزمون UI تعاملی	عالی برای UIهای پویا و بی‌درنگ	UIهای ساده را مدیریت می‌کند، اما برای تعامل‌های غنی پرگوتر و پیچیده‌تر است
آزمون بارگذاری فایل	API هوشمندتر برای بارگذاری فایل	پرگوتر، API کمتر شهودی
ادغام CI/CD	ادغام آسان با GitHub Actions، Jenkins	ادغام قوی با ابزارهای CI بسیار
آزمون موبایل	محدود، فقط شبیه‌سازی	پشتیبانی کامل از طریق Appium
پشتیبانی میان‌مرورگری	Chromium، WebKit، Firefox	پشتیبانی کامل در مرورگرهای اصلی و قدیمی
کارایی	سریع، بهینه برای آزمون headless	کندتر، به‌ویژه در حالت headless
آزمون چندمانیتوره	محدود	پشتیبانی خوب از چینش‌های چندمانیتوره
جامعه و اکوسیستم	رو به رشد، مستندات خوب	بزرگ، بالغ، اکوسیستم وسیع

7. تصمیم

پس از بررسی نیازمندی‌ها و مصالحه‌ها، Playwright انتخاب بهتری برای نیازهای کنونی ماست. API هوشمندتر آن برای آزمون بارگذاری فایل محلی، نحو موجز و پشتیبانی قوی از آزمون UI تعاملی آن را به تناسبی ایده‌آل برای چرخهٔ توسعهٔ چابک ما تبدیل می‌کند. اینکه از هر دو TypeScript و Python پشتیبانی می‌کند برای تیم ما حیاتی است و رویکرد مدرن چارچوب به آزمون به ما اجازه می‌دهد کد تمیز و نگهداری‌پذیر بنویسیم.

هرچند Selenium ابزار عالی‌ای باقی می‌ماند، به‌ویژه برای آزمون موبایل، پشتیبانی مرورگرهای قدیمی و چینش‌های چندمانیتوره، برای نیازهای کنونی ما کمتر مناسب است. پرگویی، کارایی کندتر و مدیریت پیچیده‌تر آن از UIهای پویا مانند نمودارها آن را برای مورد استفادهٔ ما کمتر بهینه می‌کند.

8. پیامدها

• اقدام فوری: برای آزمون E2E خود Playwright را اتخاذ خواهیم کرد و بر آزمودن جریان‌های کاربری شامل ثبت‌نام، ورود، بارگذاری فایل، داشبوردها و دانلود گزارش‌ها تمرکز می‌کنیم.
• ملاحظات بلندمدت: اکوسیستم در حال تکامل Playwright را زیر نظر خواهیم داشت. اگر نیازهای ما تغییر کند، به‌ویژه دربارهٔ آزمون موبایل یا پشتیبانی از مرورگرهای قدیمی، ممکن است به Selenium بازگردیم.
• آموزش و مستندسازی: تیم‌های توسعه باید با API مربوط به Playwright، به‌ویژه برای مدیریت UIهای پویا و بارگذاری فایل، آشنا شوند.
• مهاجرت: آزمون‌های Selenium موجود (در صورت وجود) به‌تدریج به Playwright مهاجرت داده خواهند شد.

9. ملاحظات آینده