Summarize this content to 400 words in Persian Lang در یکی از پروژه های مشتری خود، باید در مورد یک چارچوب آزمایشی end-to-end (e2e) تصمیم می گرفتیم. در حالی که ما با Cypress آشنا بودیم، می خواستیم گزینه جدیدتری، نمایشنامه نویس را بررسی کنیم. ما نحوه پرداختن هر دو چارچوب به موضوعاتی را که برای ما مهم‌تر بودند، مقایسه کردیم و به ما اجازه داد معیارهایی را برای تصمیم‌گیری آگاهانه تعیین کنیم. من مایلم برخی از نکات کلیدی را که مورد بحث قرار دادیم و نتایجی که به آن رسیدیم را خلاصه کنم.

1. نصب و راه اندازی

هر دو چارچوب ارائه می دهند npx اسکریپت هایی که نصب بسته را مدیریت می کنند و تست های نمونه ایجاد می کنند تا به کاربران کمک کنند تا چارچوب را درک کنند. آنها همچنین تصاویر Docker را ارائه می دهند که می توانند برای ادغام CI استفاده شوند. در حالی که تمام وابستگی های لازم برای Playwright در آن ذخیره می شود node_modules (با مرورگرهای موجود در باینری)، Cypress به آنچه در سیستم (یا تصویر داکر) ارائه شده است، متکی است. شایان ذکر است که Cypress باینری به صورت جهانی در سیستم ذخیره می شود، که اگر روی یک رایانه شخصی شرکتی با حقوق محدود برای نصب نرم افزار کار می کنید، می تواند نصب را پیچیده کند. این یک مفهوم دیگر دارد: اگر می‌خواهید وابستگی‌ها را بین کارهای CI ذخیره کنید، باید دایرکتوری کش را تنظیم کنید و آن را در کنار آن ذخیره کنید. node_modules.

2. اکسپلورر را تست کنید

یک کاوشگر تست جامع برای پیمایش و اجرای یکپارچه تست ها ضروری است. هر دو چارچوب این قابلیت را ارائه می دهند، اما تجربه توسعه دهنده (DX) متفاوت است. Cypress برنامه واقعی را در اکسپلورر خود ارائه می دهد و به توسعه دهندگان این امکان را می دهد که روی برنامه کلیک کرده و آزمایش ها را پس از اتمام اجرا بررسی کنند. Playwright عملکرد مشابهی را ارائه می دهد، اما به جای ارائه برنامه واقعی، اسکرین شات های برنامه را در یک جدول زمانی نمایش می دهد. ممکن است این یک محدودیت به نظر برسد، اما خوشبختانه یک افزونه VSCode وجود دارد که به غلبه بر آن کمک می کند.

3. نحو و محیط اجرا

هر دو چارچوب تست از TypeScript پشتیبانی می کنند. Cypress رویدادهای ناهمزمان را با پوششی که شبیه Promises به نظر می‌رسد مدیریت می‌کند، در حالی که Playwright از Promises بومی استفاده می‌کند و از نحو async/wait پشتیبانی می‌کند. توجه به این نکته مهم است که کد Cypress در مرورگر اجرا می شود، در حالی که Playwright در یک محیط Node اجرا می شود و از طریق پروتکل DevTools با مرورگر ارتباط برقرار می کند. در نتیجه، متغیرهای محیطی را می‌توان مستقیماً در زمان اجرا در دسترس قرار داد، که ممکن است برای ارسال اعتبار کاربر آزمایشی یا سایر داده‌های مرتبط با آزمایش مفید باشد.

در زیر قطعه کدهایی از ظاهر آزمایشات برای هر دو فریمورک را خواهید دید. به خاطر داشته باشید که همه انتخابگرها به طور خودکار توسط ابزار انتخاب مکان یاب (موجود در هر دو چارچوب) انتخاب شده اند.

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

نمونه آزمون نمایشنامه نویس. این فریم ورک از نحو بومی async/wait استفاده می کند، بنابراین هر دستور به ترتیبی که انتظار می رود اجرا می شود.

4. اجرای آزمون موازی

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

5. تست API

در پروژه خود، ما می خواستیم برخی از عملکردها را با تست های API پوشش دهیم. ایده اولیه ما استفاده از “Jest” برای این منظور بود، اما لازم است مکانیزمی را برای مدیریت توکن‌های اعتبار اجرا کنیم. با هر چهارچوب (نمایشنامه نویس یا سرو)، این فرآیند ساده شده است. توکن را می توان در ابتدای جلسه آزمون با استفاده از منطق برنامه (از آنجایی که به برنامه واقعی دسترسی داریم) بدست آورد و ذخیره کرد. بعداً می توان از آن برای هر تست API استفاده مجدد کرد.

نمونه تست API با استفاده از Cypress. Cypress از کتابخانه ادعای چای استفاده می کند. ممکن است بخواهید آن را با ماژول های اضافی گسترش دهید، تا امکان بررسی عمیق آرایه ها یا بررسی زیرمجموعه خصوصیات در شیء نتیجه را فراهم کنید.

نمونه تست API با استفاده از Playwright. برای کسانی که با جست آشنا هستند، نحو نمایشنامه نویس آشنا به نظر می رسد. دارای ادعاهای عمومی داخلی است، کلاسی که به ما امکان می دهد بررسی کنیم که آیا یک شی دریافت شده حاوی مقدار خاصی است، آیا یک مقدار به مقدار دیگر نزدیک است یا یک مقدار از نوع خاصی است و غیره.

6. زبانه های مختلف مرورگر، تغییر مبدا در طول آزمایش

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

7. Viewports موبایل

هر دو Cypress و Playwright از تست در نماهای موبایل پشتیبانی می کنند و وضوح های از پیش تعریف شده را برای دستگاه های مختلف ارائه می دهند. به نظر می رسد فهرست نمایشنامه نویس از سرو بلندتر است. در هر دو مورد، وضوح را می توان به صورت سراسری (یا در هر پروژه در مورد نمایشنامه نویس) یا در یک مورد آزمایشی تنظیم کرد. با این حال، مهم است که توجه داشته باشید که این در مورد شبیه سازی یک دستگاه نیست، بلکه وضوح دستگاه است. برای آزمایش کامل در سناریوهای واقعی، ابزارهای خارجی مانند Browserstack یا Lambdtest ضروری هستند.

8. مقایسه بصری

اگر می خواهید مطمئن شوید که CSS شما پس از تغییر خراب نمی شود، تست های مقایسه بصری ایده خوبی هستند. هر دو چارچوب از این گزینه پشتیبانی می کنند، اما با سطوح مختلف سادگی پذیرش. در نمایشنامه نویس، آن را خارج از جعبه کار می کند. شما به سادگی تماس بگیرید await expect(page).toHaveScreenshot();. اگر از قبل تعریف نشده باشد، این تابع یک اسکرین شات جدید ایجاد می کند. در غیر این صورت، عکس فوری فعلی را با آنچه در پروژه ذخیره شده است مقایسه می کند، بدون نیاز به تنظیمات اضافی. از سوی دیگر، Cypress به صورت بومی از این پشتیبانی نمی کند، بنابراین باید به افزونه های خارجی تکیه کنید. توصیه می کنم اسناد رسمی Cypress را بررسی کنید تا ببینید چه ابزارهایی توصیه می شود.

خلاصه

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

متفرقه

در مورد ما، اجرای آزمایشات روی CI بسیار کند بود. پس از بررسی، متوجه شدیم که مشکل پیکربندی نادرست تنظیمات Playwrit ما به‌ویژه، پیکربندی ردیابی بیننده است. ما از تنظیمات Retain-on-Filure استفاده می کردیم که ردیابی را برای تمام مشخصات ثبت می کند. این منجر به نیاز به ذخیره تعداد زیادی فایل شد که برای رانر GitLab ما بسیار وقت گیر بود. جابجایی به گزینه “اولین تلاش مجدد” مشکل را حل کرد.

در یکی از پروژه های مشتری خود، باید در مورد یک چارچوب آزمایشی end-to-end (e2e) تصمیم می گرفتیم. در حالی که ما با Cypress آشنا بودیم، می خواستیم گزینه جدیدتری، نمایشنامه نویس را بررسی کنیم. ما نحوه پرداختن هر دو چارچوب به موضوعاتی را که برای ما مهم‌تر بودند، مقایسه کردیم و به ما اجازه داد معیارهایی را برای تصمیم‌گیری آگاهانه تعیین کنیم. من مایلم برخی از نکات کلیدی را که مورد بحث قرار دادیم و نتایجی که به آن رسیدیم را خلاصه کنم.

1. نصب و راه اندازی

هر دو چارچوب ارائه می دهند npx اسکریپت هایی که نصب بسته را مدیریت می کنند و تست های نمونه ایجاد می کنند تا به کاربران کمک کنند تا چارچوب را درک کنند. آنها همچنین تصاویر Docker را ارائه می دهند که می توانند برای ادغام CI استفاده شوند. در حالی که تمام وابستگی های لازم برای Playwright در آن ذخیره می شود node_modules (با مرورگرهای موجود در باینری)، Cypress به آنچه در سیستم (یا تصویر داکر) ارائه شده است، متکی است. شایان ذکر است که Cypress باینری به صورت جهانی در سیستم ذخیره می شود، که اگر روی یک رایانه شخصی شرکتی با حقوق محدود برای نصب نرم افزار کار می کنید، می تواند نصب را پیچیده کند. این یک مفهوم دیگر دارد: اگر می‌خواهید وابستگی‌ها را بین کارهای CI ذخیره کنید، باید دایرکتوری کش را تنظیم کنید و آن را در کنار آن ذخیره کنید. node_modules.

2. اکسپلورر را تست کنید

یک کاوشگر تست جامع برای پیمایش و اجرای یکپارچه تست ها ضروری است. هر دو چارچوب این قابلیت را ارائه می دهند، اما تجربه توسعه دهنده (DX) متفاوت است. Cypress برنامه واقعی را در اکسپلورر خود ارائه می دهد و به توسعه دهندگان این امکان را می دهد که روی برنامه کلیک کرده و آزمایش ها را پس از اتمام اجرا بررسی کنند. Playwright عملکرد مشابهی را ارائه می دهد، اما به جای ارائه برنامه واقعی، اسکرین شات های برنامه را در یک جدول زمانی نمایش می دهد. ممکن است این یک محدودیت به نظر برسد، اما خوشبختانه یک افزونه VSCode وجود دارد که به غلبه بر آن کمک می کند.

3. نحو و محیط اجرا

هر دو چارچوب تست از TypeScript پشتیبانی می کنند. Cypress رویدادهای ناهمزمان را با پوششی که شبیه Promises به نظر می‌رسد مدیریت می‌کند، در حالی که Playwright از Promises بومی استفاده می‌کند و از نحو async/wait پشتیبانی می‌کند. توجه به این نکته مهم است که کد Cypress در مرورگر اجرا می شود، در حالی که Playwright در یک محیط Node اجرا می شود و از طریق پروتکل DevTools با مرورگر ارتباط برقرار می کند. در نتیجه، متغیرهای محیطی را می‌توان مستقیماً در زمان اجرا در دسترس قرار داد، که ممکن است برای ارسال اعتبار کاربر آزمایشی یا سایر داده‌های مرتبط با آزمایش مفید باشد.

در زیر قطعه کدهایی از ظاهر آزمایشات برای هر دو فریمورک را خواهید دید. به خاطر داشته باشید که همه انتخابگرها به طور خودکار توسط ابزار انتخاب مکان یاب (موجود در هر دو چارچوب) انتخاب شده اند.

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

نمونه آزمون نمایشنامه نویس. این فریم ورک از نحو بومی async/wait استفاده می کند، بنابراین هر دستور به ترتیبی که انتظار می رود اجرا می شود.

4. اجرای آزمون موازی

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

5. تست API

در پروژه خود، ما می خواستیم برخی از عملکردها را با تست های API پوشش دهیم. ایده اولیه ما استفاده از “Jest” برای این منظور بود، اما لازم است مکانیزمی را برای مدیریت توکن‌های اعتبار اجرا کنیم. با هر چهارچوب (نمایشنامه نویس یا سرو)، این فرآیند ساده شده است. توکن را می توان در ابتدای جلسه آزمون با استفاده از منطق برنامه (از آنجایی که به برنامه واقعی دسترسی داریم) بدست آورد و ذخیره کرد. بعداً می توان از آن برای هر تست API استفاده مجدد کرد.

نمونه تست API با استفاده از Cypress. Cypress از کتابخانه ادعای چای استفاده می کند. ممکن است بخواهید آن را با ماژول های اضافی گسترش دهید، تا امکان بررسی عمیق آرایه ها یا بررسی زیرمجموعه خصوصیات در شیء نتیجه را فراهم کنید.

نمونه تست API با استفاده از Playwright. برای کسانی که با جست آشنا هستند، نحو نمایشنامه نویس آشنا به نظر می رسد. دارای ادعاهای عمومی داخلی است، کلاسی که به ما امکان می دهد بررسی کنیم که آیا یک شی دریافت شده حاوی مقدار خاصی است، آیا یک مقدار به مقدار دیگر نزدیک است یا یک مقدار از نوع خاصی است و غیره.

6. زبانه های مختلف مرورگر، تغییر مبدا در طول آزمایش

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

7. Viewports موبایل

هر دو Cypress و Playwright از تست در نماهای موبایل پشتیبانی می کنند و وضوح های از پیش تعریف شده را برای دستگاه های مختلف ارائه می دهند. به نظر می رسد فهرست نمایشنامه نویس از سرو بلندتر است. در هر دو مورد، وضوح را می توان به صورت سراسری (یا در هر پروژه در مورد نمایشنامه نویس) یا در یک مورد آزمایشی تنظیم کرد. با این حال، مهم است که توجه داشته باشید که این در مورد شبیه سازی یک دستگاه نیست، بلکه وضوح دستگاه است. برای آزمایش کامل در سناریوهای واقعی، ابزارهای خارجی مانند Browserstack یا Lambdtest ضروری هستند.

8. مقایسه بصری

اگر می خواهید مطمئن شوید که CSS شما پس از تغییر خراب نمی شود، تست های مقایسه بصری ایده خوبی هستند. هر دو چارچوب از این گزینه پشتیبانی می کنند، اما با سطوح مختلف سادگی پذیرش. در نمایشنامه نویس، آن را خارج از جعبه کار می کند. شما به سادگی تماس بگیرید await expect(page).toHaveScreenshot();. اگر از قبل تعریف نشده باشد، این تابع یک اسکرین شات جدید ایجاد می کند. در غیر این صورت، عکس فوری فعلی را با آنچه در پروژه ذخیره شده است مقایسه می کند، بدون نیاز به تنظیمات اضافی. از سوی دیگر، Cypress به صورت بومی از این پشتیبانی نمی کند، بنابراین باید به افزونه های خارجی تکیه کنید. توصیه می کنم اسناد رسمی Cypress را بررسی کنید تا ببینید چه ابزارهایی توصیه می شود.

خلاصه

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

متفرقه

در مورد ما، اجرای آزمایشات روی CI بسیار کند بود. پس از بررسی، متوجه شدیم که مشکل پیکربندی نادرست تنظیمات Playwrit ما به‌ویژه، پیکربندی ردیابی بیننده است. ما از تنظیمات Retain-on-Filure استفاده می کردیم که ردیابی را برای تمام مشخصات ثبت می کند. این منجر به نیاز به ذخیره تعداد زیادی فایل شد که برای رانر GitLab ما بسیار وقت گیر بود. جابجایی به گزینه “اولین تلاش مجدد” مشکل را حل کرد.