«اجرای ۱۰۰ تست Playwright به‌صورت موازی بدون تداخل صندوق‌ورودی»

اصل ماجرا

تست‌های Playwright که به ایمیل‌های تأیید نیاز دارند، معمولاً در CI به‌دلیل استفاده از صندوق مشترک با مشکل تداخل مواجه می‌شوند. ZeroDrop برای هر اجرا یک صندوق ایمیل تصادفی و ایزوله می‌سازد، لذا هیچ‌کدام از کارهای موازی ایمیل یکدیگر را نمی‌خوانند. این روش در GitHub Actions با ماتریس ۴ کارگر به‌سادگی پیاده شد و می‌توان آن را به‌آسانی به ۱۰۰ کارگر گسترش داد.

متن کامل ترجمه‌شده

اگر تا به حال سعی کرده اید یک مجموعه از آزمایشات Playwright بزرگ را با هم اجرا کنید – نوعی که جریان های تایید ایمیل، لینک های جادویی و یا تنظیمات رمز عبور را تست می کند – احتمالاً این مشکل را حل کرده اید: دو آزمایش در همان زمان اجرا می شود. هر دو با همان آدرس ایمیل تست ثبت نام می کنند. تست A منتظر ایمیل تأیید می شود. ایمیل تست B ابتدا می آید. تست A آن را می خواند. تست B بارها خارج می شود. کل مجموعه قرمز می شود، و شما یک ساعت را در یک شرایط مسابقه که تنها در CI اتفاق می افتد از بین بردن می کنید. این مشکل تصادف جعلی است، آن را متناوب می کند، و آن را به طور کامل اجتناب می کند. چرا ایمیل های مشترک در CI متناوب شکست می دهند. اکثر ابزار های تست ایمیل به شما یکی از دو گزینه را میگزینه 2: مجموعه ای محدود از جعبه های واردات بهتر است، اما هنوز هم زمانی که تعداد کارگران paralel شما بیش از جعبه های واردات می باشد، قطع می شود. ساخت یک مارتسی 20 کارگر در برابر حد 10 جعبه های واردات به معنای نصف آزمایش شما در برابر وضعیت مشترک مبارزه می کند. اصلاح واقعی ساده تر است: یک جعبه وارداتی منحصر به فرد در هر اجرا تست، همیشه. آلودگی ZeroDrop از طریق استاندارد ZeroDrop یک جعبه وارداتی جدید در هر تماس ایجاد می کند - هیچ وضعیت مشترک، هیچ جعبه ها، هیچ سازگاری: const mail = new ZeroDrop(); const inbox = mail.generateInbox(); // [email protected] هر نام جعبه وارداتی یک ادعای تصادفی + یک زنجیره آلبانی 7 علائم است. فضای آدرسدر اینجا یک مثال واقعی است - 4 کارگران paralel، هر یک از آنها یک تست فرآیند Auth جداگانه را اجرا می کنند، هر یک با جعبه ای منحصر به فرد خود را: نام: E2E Auth Tests (Parallel) در: [Push] Jobs: Test: runs-on: ubuntu-latest strategy: matrix: shard: [1, 2, 3, 4] # Run 4 کارگران در مراحل منحصر به فرد: - استفاده: actions/checkout@v4 - نام: Setup Node.js استفاده: actions/setup-node@v4 با: node-version: ‘20’ # هر کارمند خود را یک جعبه ای منحصر به فرد دریافت می کند - نام: تولید تست منحصر به فرد در idbox: جعبه ای استفاده: zerodrop-dev/create-inbox@v1 -10 کارگران، 10 جعبه واردات. 100 کارگران، 100 جعبه واردات. هیچ پوشاک برای اخراج وجود ندارد، هیچ قفل برای خرید، هیچ مرحله تمیز کردن بین اجراها. // در تست Playwright شما - کار به طور یکسان در سراسر تمام کارگران paralel واردات { تست، انتظار } از ‘@playwright/test. 100 کارگران، 100 جعبه واردات { ZeroDrop } از ‘zerodrop-inbox’; const mail = new ZeroDrop(); // process.env.TEST_INBOX توسط GitHub Action // Fall back to a fresh inbox when running locally const inbox = processen.TEST.TEST_BOX ?? mail.Inbox generate(); (‘email verification flow’, async ({ page}) => wait page.gotobody(‘signup’); wait page.toHaveURL(‘/dashboard’); }); هر کارمند کاملا خودکشی است. تست نمی داند یا به چه اندازه کارگران دیگر در حال اجرا هستند. مشکل پایگاه داده های وارد شده در مقیاس برخی از ابزارهای تست ایمیل پوشش بسته های وارد شده در برنامه های سطح پایین - به طور معمول 10 در هر حساب. اگر مارتسی CI شما بیش از 10 کارگران paralel را اجرا می کند، که در pipelines شرکت معمول است، شما یا حدود را به دست می آورید و آزمایش ها شکست می کنند، و یا شما به سطح بالاتر برای بسته های وارد شده نامحدود ارتقاء می کنید. سطح رایگان ZeroDrop هیچ محدودیت بسته های وارد شده ندارد.هر جعبه ثبت نام ZeroDrop توسط طراحی جدا شده است: - منحصر به فرد بر روی اجرا - نام تصادفی که در ابتدای تست تولید می شود، هرگز بار دیگر استفاده نمی شود - Ephemeral - خودکار پس از 30 دقیقه از طریق Redis TTL حذف می شود - خصوصی - تنها از طریق نام دقیق ثبت نام قابل دسترسی است؛ هیچ API ثبت نام - Edge-routed - ایمیل ها در محدوده جهانی Cloudflare گرفته می شوند، نه یک سرور مرکزی 30 دقیقه TTL به معنای داده های تست است که هرگز جمع نمی شود. یک جعبه آزمون که 6 ساعت پیش اجرا شد، آثار صفر را ترک کرده است. مثال کار یک تنظیم پارامتر کامل Playwright با ZeroDrop، از جمله GitHub Actions Matrix تنظیمات و تست های اتوماتیک کامل: → github.com/zerodrop-devzerop/odrop-wrightبرای تیم هایی که نیاز به دامنه های سفارشی، حفظ 7 روزه و کلیدهای API مشترک دارند: → zerodrop.

چرا مهمه؟

تغییر اصلی این است که دیگر نیازی به استفاده از صندوق‌های مشترک یا محدود نیست؛ هر تست یک صندوق اختصاصی دریافت می‌کند. این تغییر برای تیم‌های تست خودکار، مهندسان CI/CD و توسعه‌دهندگان Playwright که به‌سرعت و بدون خطای زمان‌بندی می‌خواهند تست‌های ایمیل‌محور را اجرا کنند، اثرگذار است. خواننده باید به این خبر اهمیت بده چون با حذف تداخل ایمیل، زمان دیباگ کاهش می‌یابد و هزینه‌های ارتقاء پلن‌های ایمیل‌سرویس‌ها حذف می‌شود.

به درد کی می‌خوره؟

• مهندسان تست خودکار • تیم‌های DevOps • توسعه‌دهندگان Front‑end که از Playwright استفاده می‌کنند • مدیران CI/CD

تو عمل چی کار کنیم؟

با خواندن این خبر می‌توانید در پروژه‌تان ZeroDrop را به‌عنوان Action در GitHub Actions اضافه کنید و برای هر کارگر یک صندوق ایمیل جدید تولید کنید. این کار باعث می‌شود تست‌های موازی بدون خطای زمان‌سنجی اجرا شوند و نیازی به مدیریت صندوق‌های مشترک یا ارتقاء پلن‌های ایمیل‌سرویس نداشته باشید.

نظر Blue IT News

ZeroDrop نه تنها مشکل تداخل ایمیل را حل می‌کند، بلکه با طرح رایگان بدون محدودیت صندوق، هزینه‌های زیرساخت تست را به‌طور چشمگیری کاهش می‌دهد.