🔵 عنوان مقاله
Debugging "No Tests Found" Errors in Playwright: A Comprehensive Guide
🟢 خلاصه مقاله:
راهنمای Marius Besel نشان می‌دهد که خطای “No Tests Found” در Playwright معمولاً به دلیل کشف‌نشدن فایل‌های تست یا حذف‌شدن آن‌ها توسط الگوها و فیلترها رخ می‌دهد. او تأکید می‌کند ابتدا نام‌گذاری و محل فایل‌ها را بررسی کنید: Playwright به‌طور پیش‌فرض در testDir (مثلاً tests) به‌دنبال *.spec.* یا *.test.* می‌گردد و هر تغییری در testMatch/testIgnore یا اجرای دستور در مسیر اشتباه می‌تواند کشف را از کار بیندازد. سپس فیلترها و پروژه‌ها را چک کنید: پارامترهایی مثل --grep، --grep-invert، --project یا دادن مسیری که تستی در آن نیست، ممکن است همه چیز را حذف کند؛ استفاده از --list کمک می‌کند بفهمید دقیقاً چه تست‌هایی شناسایی می‌شوند. در ساختارهای monorepo، چندین فایل playwright.config و اسکریپت‌های workspace می‌توانند Playwright را به دایرکتوری‌های نادرست ببرند.
برای TypeScript، مشکلات outDir، تفاوت ESM/CJS، و تنظیمات include/exclude در tsconfig می‌تواند مانع کشف تست‌ها شود؛ هم‌تراز کردن testDir با tsconfig، پرهیز از تزاحم فرایندهای جداگانه ترنسپایل، و یکنواخت‌کردن تنظیمات ماژول معمولاً مشکل را حل می‌کند. تفاوت محیط‌ها نیز مهم است: حساسیت به حروف در Linux، مسیرها و متغیرهای محیطی در CI، و ناهمخوانی نسخه‌ها می‌توانند باعث بروز خطا شوند. جمع‌بندی او یک چک‌لیست عملی است: نام‌گذاری/محل فایل‌ها، تنظیمات testDir/testMatch/testIgnore، فیلترها و پروژه‌ها، تنظیمات TypeScript/ماژول، و یکسان‌سازی محیط محلی و CI—با این مراحل، پیام “No Tests Found” به‌سادگی برطرف می‌شود.
#Playwright #Testing #Debugging #JavaScript #TypeScript #E2E #CI #TestAutomation
🟣لینک مقاله:
https://cur.at/irqt94X?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Debugging "No Tests Found" Errors in Playwright: A Comprehensive Guide
🟢 خلاصه مقاله:
راهنمای Marius Besel نشان می‌دهد که خطای “No Tests Found” در Playwright معمولاً به دلیل کشف‌نشدن فایل‌های تست یا حذف‌شدن آن‌ها توسط الگوها و فیلترها رخ می‌دهد. او تأکید می‌کند ابتدا نام‌گذاری و محل فایل‌ها را بررسی کنید: Playwright به‌طور پیش‌فرض در testDir (مثلاً tests) به‌دنبال *.spec.* یا *.test.* می‌گردد و هر تغییری در testMatch/testIgnore یا اجرای دستور در مسیر اشتباه می‌تواند کشف را از کار بیندازد. سپس فیلترها و پروژه‌ها را چک کنید: پارامترهایی مثل --grep، --grep-invert، --project یا دادن مسیری که تستی در آن نیست، ممکن است همه چیز را حذف کند؛ استفاده از --list کمک می‌کند بفهمید دقیقاً چه تست‌هایی شناسایی می‌شوند. در ساختارهای monorepo، چندین فایل playwright.config و اسکریپت‌های workspace می‌توانند Playwright را به دایرکتوری‌های نادرست ببرند.
برای TypeScript، مشکلات outDir، تفاوت ESM/CJS، و تنظیمات include/exclude در tsconfig می‌تواند مانع کشف تست‌ها شود؛ هم‌تراز کردن testDir با tsconfig، پرهیز از تزاحم فرایندهای جداگانه ترنسپایل، و یکنواخت‌کردن تنظیمات ماژول معمولاً مشکل را حل می‌کند. تفاوت محیط‌ها نیز مهم است: حساسیت به حروف در Linux، مسیرها و متغیرهای محیطی در CI، و ناهمخوانی نسخه‌ها می‌توانند باعث بروز خطا شوند. جمع‌بندی او یک چک‌لیست عملی است: نام‌گذاری/محل فایل‌ها، تنظیمات testDir/testMatch/testIgnore، فیلترها و پروژه‌ها، تنظیمات TypeScript/ماژول، و یکسان‌سازی محیط محلی و CI—با این مراحل، پیام “No Tests Found” به‌سادگی برطرف می‌شود.
#Playwright #Testing #Debugging #JavaScript #TypeScript #E2E #CI #TestAutomation
🟣لینک مقاله:
https://cur.at/irqt94X?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Debugging “No Tests Found” Errors in Playwright: A Comprehensive Guide
When working with Playwright for end-to-end testing, few things are more frustrating than encountering the dreaded “No tests found” error…
🔵 عنوان مقاله
Mitigating supply chain attacks (2 minute read)
🟢 خلاصه مقاله:
pnpm v10 برای کاهش ریسک حملات زنجیره تأمین دو تغییر مهم اعمال می‌کند: ۱) اجرای خودکار postinstall در وابستگی‌ها به‌صورت پیش‌فرض غیرفعال شده و فقط بسته‌هایی که واقعاً به اسکریپت‌های ساخت نیاز دارند با اجازه صریح (whitelist/allowlist) اجرا می‌شوند؛ ۲) تنظیم minimumReleaseAge نصب نسخه‌های تازه‌منتشرشده را برای مدتی به‌تعویق می‌اندازد تا قبل از نصب، زمان لازم برای شناسایی و گزارش بسته‌های مخرب فراهم شود. حاصل این رویکرد، کاهش اجرای ناخواسته کد و ایجاد یک حاشیه امن برای شناسایی تهدیدات است، با هزینه‌ای اندک در سرعت به‌روزرسانی. راهکار عملی برای تیم‌ها: مشخص‌کردن بسته‌هایی که واقعاً به اسکریپت نیاز دارند و allowlist کردن آن‌ها، و تنظیم حد انتظار مناسب برای minimumReleaseAge بر اساس سطح ریسک محیط توسعه و تولید.
#pnpm #SupplyChainSecurity #OpenSourceSecurity #JavaScript #NodeJS #DevSecOps #PackageManagers #SoftwareSupplyChain
🟣لینک مقاله:
https://pnpm.io/supply-chain-security?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Mitigating supply chain attacks (2 minute read)
🟢 خلاصه مقاله:
pnpm v10 برای کاهش ریسک حملات زنجیره تأمین دو تغییر مهم اعمال می‌کند: ۱) اجرای خودکار postinstall در وابستگی‌ها به‌صورت پیش‌فرض غیرفعال شده و فقط بسته‌هایی که واقعاً به اسکریپت‌های ساخت نیاز دارند با اجازه صریح (whitelist/allowlist) اجرا می‌شوند؛ ۲) تنظیم minimumReleaseAge نصب نسخه‌های تازه‌منتشرشده را برای مدتی به‌تعویق می‌اندازد تا قبل از نصب، زمان لازم برای شناسایی و گزارش بسته‌های مخرب فراهم شود. حاصل این رویکرد، کاهش اجرای ناخواسته کد و ایجاد یک حاشیه امن برای شناسایی تهدیدات است، با هزینه‌ای اندک در سرعت به‌روزرسانی. راهکار عملی برای تیم‌ها: مشخص‌کردن بسته‌هایی که واقعاً به اسکریپت نیاز دارند و allowlist کردن آن‌ها، و تنظیم حد انتظار مناسب برای minimumReleaseAge بر اساس سطح ریسک محیط توسعه و تولید.
#pnpm #SupplyChainSecurity #OpenSourceSecurity #JavaScript #NodeJS #DevSecOps #PackageManagers #SoftwareSupplyChain
🟣لینک مقاله:
https://pnpm.io/supply-chain-security?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
pnpm.io
Mitigating supply chain attacks | pnpm
Sometimes npm packages are compromised and published with malware. Luckily, there are companies like [Socket], [Snyk], and [Aikido] that detect these compromised packages early. The npm registry usually removes the affected versions within hours. However…
🔵 عنوان مقاله
This one feature from Cypress I didn't know I needed
🟢 خلاصه مقاله:
کنیت Bati تجربه‌ی مهاجرت یک مجموعه تست انتها‌به‌انتها از Cypress به Playwright را روایت می‌کند و نشان می‌دهد تفاوت‌های کوچک چقدر در کار روزمره اثر دارند. مهم‌ترین غافلگیری او فقدان همان قابلیت «گزارش فرمان‌ها با عکس‌های لحظه‌ای DOM و زمان‌گردانی» در Cypress بود؛ قابلیتی که عیب‌یابی ناپایداری و اشکالات انتخاب‌گرها را بسیار سریع می‌کرد.
در Playwright او با فعال‌کردن Trace Viewer، استفاده هدفمند از trace در CI، تکیه بر auto-waiting و assertionهای دقیق‌تر، و افزودن خروجی‌های کمکی (لاگ شبکه، اسکرین‌شات‌های هدفمند) بیشترِ آن بازخورد را جبران کرد. با استاندارد کردن test idها و کمی بازطراحی تست‌ها برای حذف فرض‌های زمانی، جریان کاری جدید شکل گرفت و در نهایت با سرعت اجرای بالاتر به پایداری مشابه رسیدند.
جمع‌بندی: هیچ‌کدام بر دیگری مطلقاً برتری ندارند؛ اما ارگونومی ابزار سرعت تیم را می‌سازد. در مهاجرت، زمان بگذارید تا چرخه‌های بازخورد محبوب‌تان را بازسازی کنید و جاهایی که همتای مستقیم ندارند، عادت‌های جدید بسازید. این‌گونه می‌توان مزایای Playwright را به‌دست آورد بدون از دست دادن تجربه توسعه‌دهنده‌ای که با Cypress داشتید.
#Cypress #Playwright #E2ETesting #TestAutomation #Migration #QA #JavaScript
🟣لینک مقاله:
https://cur.at/ZiBGzOL?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
This one feature from Cypress I didn't know I needed
🟢 خلاصه مقاله:
کنیت Bati تجربه‌ی مهاجرت یک مجموعه تست انتها‌به‌انتها از Cypress به Playwright را روایت می‌کند و نشان می‌دهد تفاوت‌های کوچک چقدر در کار روزمره اثر دارند. مهم‌ترین غافلگیری او فقدان همان قابلیت «گزارش فرمان‌ها با عکس‌های لحظه‌ای DOM و زمان‌گردانی» در Cypress بود؛ قابلیتی که عیب‌یابی ناپایداری و اشکالات انتخاب‌گرها را بسیار سریع می‌کرد.
در Playwright او با فعال‌کردن Trace Viewer، استفاده هدفمند از trace در CI، تکیه بر auto-waiting و assertionهای دقیق‌تر، و افزودن خروجی‌های کمکی (لاگ شبکه، اسکرین‌شات‌های هدفمند) بیشترِ آن بازخورد را جبران کرد. با استاندارد کردن test idها و کمی بازطراحی تست‌ها برای حذف فرض‌های زمانی، جریان کاری جدید شکل گرفت و در نهایت با سرعت اجرای بالاتر به پایداری مشابه رسیدند.
جمع‌بندی: هیچ‌کدام بر دیگری مطلقاً برتری ندارند؛ اما ارگونومی ابزار سرعت تیم را می‌سازد. در مهاجرت، زمان بگذارید تا چرخه‌های بازخورد محبوب‌تان را بازسازی کنید و جاهایی که همتای مستقیم ندارند، عادت‌های جدید بسازید. این‌گونه می‌توان مزایای Playwright را به‌دست آورد بدون از دست دادن تجربه توسعه‌دهنده‌ای که با Cypress داشتید.
#Cypress #Playwright #E2ETesting #TestAutomation #Migration #QA #JavaScript
🟣لینک مقاله:
https://cur.at/ZiBGzOL?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
This one feature from Cypress I didn’t know I needed
So a couple of months ago I wrote an article about the start of our journey with the migration of our tests from Cypress to Playwright. And…
❤1
🔵 عنوان مقاله
k6 Scenarios & Metrics You Must Know
🟢 خلاصه مقاله:
این مرور ۲۵ دقیقه‌ای با ارائه Joan Esquivel Montero به‌صورت فشرده نشان می‌دهد چگونه با استفاده از سناریوها و متریک‌های کلیدی در k6 آزمون‌های کارایی دقیق‌تری بسازیم. ابتدا انتخاب صحیح executorها را پوشش می‌دهد: از constant-vus و ramping-vus برای پایه‌گیری، تست ماندگاری و استرس؛ per-vu-iterations و shared-iterations برای اجرای کنترل‌شده؛ و constant-arrival-rate و ramping-arrival-rate زمانی که هدفتان کنترل نرخ درخواست (RPS) است. ساختاردهی تست با setup/teardown، گروه‌بندی مراحل مهم، و برچسب‌گذاری برای تفکیک نتایج نیز توضیح داده می‌شود.
در بخش متریک‌ها، اهمیت http_req_duration (با تأکید بر صدک‌ها نه میانگین)، http_req_failed، http_reqs، iterations، vus/vus_max، checks، و حجم داده‌ها مطرح است و نحوه ساخت متریک‌های سفارشی با Trend، Counter، Gauge و Rate و برچسب‌گذاری برای تحلیل جزئی‌تر مرور می‌شود.
سپس تبدیل SLOها به thresholdهای قابل‌اجرا در k6 نشان داده می‌شود؛ مانند محدود کردن p(95) زمان پاسخ، نرخ خطا، یا حداقل RPS، و استفاده از abortOnFail برای توقف سریع. نکاتی برای جلوگیری از خطاهای رایج نیز ارائه می‌شود: هدف‌گذاری شفاف، داده و think time واقعی، رمپ منطقی، و انتخاب مدل بار مناسب (VU در برابر نرخ ورود).
در نهایت به جنبه‌های عملیاتی اشاره می‌شود: اجرای محلی و ادغام با CI/CD، ارسال نتایج به InfluxDB/Prometheus و مشاهده در Grafana، و مقیاس‌پذیری با k6 Cloud یا Kubernetes. با نسخه‌بندی اسکریپت‌ها، پارامترگذاری و برچسب‌گذاری، می‌توانید سریع‌تر عیب‌یابی کرده و محدودیت‌ها، رگرسیون‌ها و نقاط گلوگاهی را با دقت شناسایی کنید.
#k6 #PerformanceTesting #LoadTesting #DevOps #JavaScript #Grafana #Metrics #SRE
🟣لینک مقاله:
https://cur.at/U5oID4d?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
k6 Scenarios & Metrics You Must Know
🟢 خلاصه مقاله:
این مرور ۲۵ دقیقه‌ای با ارائه Joan Esquivel Montero به‌صورت فشرده نشان می‌دهد چگونه با استفاده از سناریوها و متریک‌های کلیدی در k6 آزمون‌های کارایی دقیق‌تری بسازیم. ابتدا انتخاب صحیح executorها را پوشش می‌دهد: از constant-vus و ramping-vus برای پایه‌گیری، تست ماندگاری و استرس؛ per-vu-iterations و shared-iterations برای اجرای کنترل‌شده؛ و constant-arrival-rate و ramping-arrival-rate زمانی که هدفتان کنترل نرخ درخواست (RPS) است. ساختاردهی تست با setup/teardown، گروه‌بندی مراحل مهم، و برچسب‌گذاری برای تفکیک نتایج نیز توضیح داده می‌شود.
در بخش متریک‌ها، اهمیت http_req_duration (با تأکید بر صدک‌ها نه میانگین)، http_req_failed، http_reqs، iterations، vus/vus_max، checks، و حجم داده‌ها مطرح است و نحوه ساخت متریک‌های سفارشی با Trend، Counter، Gauge و Rate و برچسب‌گذاری برای تحلیل جزئی‌تر مرور می‌شود.
سپس تبدیل SLOها به thresholdهای قابل‌اجرا در k6 نشان داده می‌شود؛ مانند محدود کردن p(95) زمان پاسخ، نرخ خطا، یا حداقل RPS، و استفاده از abortOnFail برای توقف سریع. نکاتی برای جلوگیری از خطاهای رایج نیز ارائه می‌شود: هدف‌گذاری شفاف، داده و think time واقعی، رمپ منطقی، و انتخاب مدل بار مناسب (VU در برابر نرخ ورود).
در نهایت به جنبه‌های عملیاتی اشاره می‌شود: اجرای محلی و ادغام با CI/CD، ارسال نتایج به InfluxDB/Prometheus و مشاهده در Grafana، و مقیاس‌پذیری با k6 Cloud یا Kubernetes. با نسخه‌بندی اسکریپت‌ها، پارامترگذاری و برچسب‌گذاری، می‌توانید سریع‌تر عیب‌یابی کرده و محدودیت‌ها، رگرسیون‌ها و نقاط گلوگاهی را با دقت شناسایی کنید.
#k6 #PerformanceTesting #LoadTesting #DevOps #JavaScript #Grafana #Metrics #SRE
🟣لینک مقاله:
https://cur.at/U5oID4d?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
YouTube
k6 Scenarios & Metrics You Must Know
Learn how to do API load testing with k6 step by step using the QuickPizza demo app 🍕. In this tutorial, you’ll see how to spin up QuickPizza with Docker, configure smoke and stress scenarios in k6, create custom metrics and thresholds, and analyze everything…
🔵 عنوان مقاله
How Playwright Runs Workers and Test Fixtures (Parallel vs Serial vs Default)!
🟢 خلاصه مقاله:
این مقاله از Thananjayan Rajasekaran به‌صورت عملی نشان می‌دهد Playwright Test چگونه workers و test fixtures را مدیریت می‌کند و تفاوت حالت‌های default، parallel و serial چیست. ابتدا توضیح می‌دهد که به‌طور پیش‌فرض فایل‌های تست روی چند worker به‌صورت موازی اجرا می‌شوند اما تست‌های داخل هر فایل به‌صورت ترتیبی اجرا می‌گردند؛ همچنین به تعامل retries، projects و گزینه‌هایی مانند --workers و sharding برای کنترل سرعت و پایداری اشاره می‌کند. سپس روش‌های افزایش همزمانی را بررسی می‌کند: فعال‌کردن fullyParallel در تنظیمات یا استفاده از test.describe.configure({ mode: 'parallel' }) برای موازی‌سازی بخشی از تست‌ها، همراه با هشدار درباره ریسک‌های وضعیت مشترک و flaky شدن. در بخش serial، با test.describe.serial یا تنظیم mode: 'serial' می‌توان اجرای ترتیبی و توقف زنجیره پس از شکست را تضمین کرد؛ راهکاری که برای گردش‌کارهای وابسته یا منابع غیرقابل‌اشتراک میان workers مفید است، هرچند توصیه می‌شود فقط در صورت نیاز استفاده شود. بخش مهم دیگر به fixtures می‌پردازد: تفاوت بین per-test و worker-scoped و تأثیر مستقیم آن‌ها بر موازی‌سازی؛ اینکه worker-scoped بین workers به‌اشتراک گذاشته نمی‌شود و ممکن است چند نمونه مستقل از یک منبع ایجاد شود. مقاله با نمونه‌کدهای روشن برای تنظیم workers، فعال‌سازی fullyParallel، علامت‌گذاری suiteها به‌صورت serial یا parallel و ترکیب آن‌ها با projects و retries، یک الگوی ذهنی شفاف برای انتخاب بهینه بین default، parallel و serial ارائه می‌دهد تا هم سرعت اجرا بالا برود و هم پایداری CI حفظ شود.
#Playwright #Testing #E2E #ParallelTesting #TestAutomation #JavaScript #Fixtures #CI
🟣لینک مقاله:
https://cur.at/93wY1jL?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How Playwright Runs Workers and Test Fixtures (Parallel vs Serial vs Default)!
🟢 خلاصه مقاله:
این مقاله از Thananjayan Rajasekaran به‌صورت عملی نشان می‌دهد Playwright Test چگونه workers و test fixtures را مدیریت می‌کند و تفاوت حالت‌های default، parallel و serial چیست. ابتدا توضیح می‌دهد که به‌طور پیش‌فرض فایل‌های تست روی چند worker به‌صورت موازی اجرا می‌شوند اما تست‌های داخل هر فایل به‌صورت ترتیبی اجرا می‌گردند؛ همچنین به تعامل retries، projects و گزینه‌هایی مانند --workers و sharding برای کنترل سرعت و پایداری اشاره می‌کند. سپس روش‌های افزایش همزمانی را بررسی می‌کند: فعال‌کردن fullyParallel در تنظیمات یا استفاده از test.describe.configure({ mode: 'parallel' }) برای موازی‌سازی بخشی از تست‌ها، همراه با هشدار درباره ریسک‌های وضعیت مشترک و flaky شدن. در بخش serial، با test.describe.serial یا تنظیم mode: 'serial' می‌توان اجرای ترتیبی و توقف زنجیره پس از شکست را تضمین کرد؛ راهکاری که برای گردش‌کارهای وابسته یا منابع غیرقابل‌اشتراک میان workers مفید است، هرچند توصیه می‌شود فقط در صورت نیاز استفاده شود. بخش مهم دیگر به fixtures می‌پردازد: تفاوت بین per-test و worker-scoped و تأثیر مستقیم آن‌ها بر موازی‌سازی؛ اینکه worker-scoped بین workers به‌اشتراک گذاشته نمی‌شود و ممکن است چند نمونه مستقل از یک منبع ایجاد شود. مقاله با نمونه‌کدهای روشن برای تنظیم workers، فعال‌سازی fullyParallel، علامت‌گذاری suiteها به‌صورت serial یا parallel و ترکیب آن‌ها با projects و retries، یک الگوی ذهنی شفاف برای انتخاب بهینه بین default، parallel و serial ارائه می‌دهد تا هم سرعت اجرا بالا برود و هم پایداری CI حفظ شود.
#Playwright #Testing #E2E #ParallelTesting #TestAutomation #JavaScript #Fixtures #CI
🟣لینک مقاله:
https://cur.at/93wY1jL?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
How Playwright Runs Workers and Test Fixtures (Parallel vs Serial vs Default)!
If you are using a playwright for quite some time, definitely you use fixture or parallel execution or both, In this blog we will see how…
❤1