🔵 عنوان مقاله
Make Selenium Test Smarter with AI — Local/Cloud LLMs
🟢 خلاصه مقاله:
این ویدئوی کوتاه از Karthik K.K. نشان میدهد چگونه میتوان با ترکیب Selenium و AI (بهویژه LLMs)، فرایند تست خودکار را هوشمندتر کرد. تمرکز بر قابلیتهایی مانند تولید خودکار اسکریپت از توضیحات طبیعی، self-healing برای locatorها، ساخت assertionهای معنادار، و تحلیل خطاها و لاگها برای ریشهیابی سریعتر است. همچنین به مزایا و معایب LLMهای Local در برابر Cloud پرداخته میشود: حفظ داده و هزینه قابل پیشبینی در Local در مقابل کیفیت، مقیاسپذیری و سهولت اتصال در Cloud. در نهایت، رویکردی گامبهگام برای شروع پیشنهاد میشود تا تیمها بدون جایگزینکردن مهارت مهندس تست، با افزودن AI به Selenium، سرعت تولید تست، پایداری و کیفیت بازخورد را بهبود دهند.
#Selenium #AI #LLM #TestAutomation #SoftwareTesting #QA #DevTools #CI_CD
🟣لینک مقاله:
https://cur.at/NrcEq81?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Make Selenium Test Smarter with AI — Local/Cloud LLMs
🟢 خلاصه مقاله:
این ویدئوی کوتاه از Karthik K.K. نشان میدهد چگونه میتوان با ترکیب Selenium و AI (بهویژه LLMs)، فرایند تست خودکار را هوشمندتر کرد. تمرکز بر قابلیتهایی مانند تولید خودکار اسکریپت از توضیحات طبیعی، self-healing برای locatorها، ساخت assertionهای معنادار، و تحلیل خطاها و لاگها برای ریشهیابی سریعتر است. همچنین به مزایا و معایب LLMهای Local در برابر Cloud پرداخته میشود: حفظ داده و هزینه قابل پیشبینی در Local در مقابل کیفیت، مقیاسپذیری و سهولت اتصال در Cloud. در نهایت، رویکردی گامبهگام برای شروع پیشنهاد میشود تا تیمها بدون جایگزینکردن مهارت مهندس تست، با افزودن AI به Selenium، سرعت تولید تست، پایداری و کیفیت بازخورد را بهبود دهند.
#Selenium #AI #LLM #TestAutomation #SoftwareTesting #QA #DevTools #CI_CD
🟣لینک مقاله:
https://cur.at/NrcEq81?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
YouTube
Make Selenium Test Smarter with AI - Local/Cloud LLMs
Your Selenium tests fail when the UI changes. Your locators break constantly. Your test maintenance is eating up your time. What if I told you AI could fix all of this with minimal code changes?
🤖 https://www.udemy.com/course/genai-multi-agent-software-…
🤖 https://www.udemy.com/course/genai-multi-agent-software-…
🔵 عنوان مقاله
Mutation testing — not just for unit tests
🟢 خلاصه مقاله:
mutation testing روشی برای سنجش کیفیت واقعی آزمونهاست: با ایجاد تغییرات کوچک در کد، بررسی میکند آیا تستها میتوانند خطاهای احتمالی را کشف کنند یا نه. این رویکرد فقط مخصوص unit tests نیست؛ میتوان آن را در سطح integration و API و حتی سناریوهای انتها به انتها بهکار گرفت تا مطمئن شویم تستها رفتار قابل مشاهده را بهخوبی پوشش میدهند. Bas Dijkstra با یک مثال گامبهگام نشان میدهد چگونه ابزار را پیکربندی کنیم، mutants بسازیم، تستها را اجرا کنیم و نتایج را تفسیر کنیم؛ و چگونه با تقویت assertions، افزودن سناریوهای لبه، یا حذف کد مرده کیفیت را بالا ببریم. پیشنهاد عملی این است که با یک بخش کوچک شروع کنید، ابزار مناسب پشتهتان را انتخاب کنید، در CI آستانههای معقول بگذارید و اجرای سنگینتر را دورهای انجام دهید تا با هزینه منطقی، بازخورد مؤثر بگیرید.
#MutationTesting #SoftwareTesting #UnitTesting #TestQuality #BasDijkstra #CodeCoverage #CI_CD #DevOps
🟣لینک مقاله:
https://cur.at/gKlipIY?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Mutation testing — not just for unit tests
🟢 خلاصه مقاله:
mutation testing روشی برای سنجش کیفیت واقعی آزمونهاست: با ایجاد تغییرات کوچک در کد، بررسی میکند آیا تستها میتوانند خطاهای احتمالی را کشف کنند یا نه. این رویکرد فقط مخصوص unit tests نیست؛ میتوان آن را در سطح integration و API و حتی سناریوهای انتها به انتها بهکار گرفت تا مطمئن شویم تستها رفتار قابل مشاهده را بهخوبی پوشش میدهند. Bas Dijkstra با یک مثال گامبهگام نشان میدهد چگونه ابزار را پیکربندی کنیم، mutants بسازیم، تستها را اجرا کنیم و نتایج را تفسیر کنیم؛ و چگونه با تقویت assertions، افزودن سناریوهای لبه، یا حذف کد مرده کیفیت را بالا ببریم. پیشنهاد عملی این است که با یک بخش کوچک شروع کنید، ابزار مناسب پشتهتان را انتخاب کنید، در CI آستانههای معقول بگذارید و اجرای سنگینتر را دورهای انجام دهید تا با هزینه منطقی، بازخورد مؤثر بگیرید.
#MutationTesting #SoftwareTesting #UnitTesting #TestQuality #BasDijkstra #CodeCoverage #CI_CD #DevOps
🟣لینک مقاله:
https://cur.at/gKlipIY?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
On Test Automation
Mutation testing - not just for unit tests
I wrote about mutation testing a few times on this blog, and I even have a mutation testing workshop that I run on a pretty frequent basis.
🎉1
🔵 عنوان مقاله
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…
🔵 عنوان مقاله
WOW. Playwright is significantly better than Selenium
🟢 خلاصه مقاله:
این روزها بسیاری از تسترها میگویند Playwright نسبت به Selenium برتری چشمگیری دارد و بحثهای Reddit نیز با تجربههای واقعیِ مهاجرت این موضوع را تأیید میکند. مهمترین مزیتها: کاهش چشمگیر فلِیکی بهخاطر auto-waiting و زمانبندی هوشمند، API مدرن و سازگار در مرورگرهای مختلف، و ابزارهای یکپارچه مثل test runner، اجرای موازی، tracing، و ضبط ویدئو/اسکرینشات که دیباگ را ساده و چرخه بازخورد در CI/CD را کوتاه میکنند. بسیاری گزارش دادهاند که با Playwright کد کمتر، پایداری بیشتر و پوشش cross-browser روانتری دارند. با این حال، در کنار این مزایا به بلوغ و اکوسیستم گسترده Selenium هم اشاره میشود؛ انتخاب نهایی به نیازها و زمینه پروژه وابسته است، اما برای تیمهایی که سرعت، پایداری و تجربه توسعهدهنده را در اولویت میگذارند، Playwright گزینه برتر جلوه میکند.
#Playwright #Selenium #TestAutomation #WebTesting #QA #E2E #CI_CD #Reddit
🟣لینک مقاله:
https://cur.at/Dwk29o1?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
WOW. Playwright is significantly better than Selenium
🟢 خلاصه مقاله:
این روزها بسیاری از تسترها میگویند Playwright نسبت به Selenium برتری چشمگیری دارد و بحثهای Reddit نیز با تجربههای واقعیِ مهاجرت این موضوع را تأیید میکند. مهمترین مزیتها: کاهش چشمگیر فلِیکی بهخاطر auto-waiting و زمانبندی هوشمند، API مدرن و سازگار در مرورگرهای مختلف، و ابزارهای یکپارچه مثل test runner، اجرای موازی، tracing، و ضبط ویدئو/اسکرینشات که دیباگ را ساده و چرخه بازخورد در CI/CD را کوتاه میکنند. بسیاری گزارش دادهاند که با Playwright کد کمتر، پایداری بیشتر و پوشش cross-browser روانتری دارند. با این حال، در کنار این مزایا به بلوغ و اکوسیستم گسترده Selenium هم اشاره میشود؛ انتخاب نهایی به نیازها و زمینه پروژه وابسته است، اما برای تیمهایی که سرعت، پایداری و تجربه توسعهدهنده را در اولویت میگذارند، Playwright گزینه برتر جلوه میکند.
#Playwright #Selenium #TestAutomation #WebTesting #QA #E2E #CI_CD #Reddit
🟣لینک مقاله:
https://cur.at/Dwk29o1?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Reddit
From the softwaretesting community on Reddit
Explore this post and more from the softwaretesting community
🔵 عنوان مقاله
Testing and Programming Are Not Separate Disciplines
🟢 خلاصه مقاله:
** این یادآوری از Ravisuriya Eswara تأکید میکند که توسعه و تست نرمافزار باید یک فرایند یکپارچه باشند، نه دو رشته جدا. با وارد کردن تست در متن کار روزانه—از تعریف معیارهای پذیرش و شناسایی ریسکها تا نوشتن تستها کنار کد، اجرای TDD و پایپلاینهای CI/CD—کیفیت از ابتدا طراحی میشود، نه در انتها ارزیابی.
این رویکرد مزایایی مانند کاهش نقیصههای تولید، بازخورد سریعتر، تحویل قابلپیشبینی، تجربه کاربری بهتر و هزینه نگهداری کمتر دارد. همکاری جایگزین تحویلهای مرحلهای میشود: توسعهدهندگان بر طراحیِ قابلتست تمرکز میکنند و تسترها با نگاه اکتشافی و کلنگر کیفیت را غنی میکنند؛ اتوماسیون و تست اکتشافی مکمل هماند. نتیجه، چرخهای سالمتر و محصولی پایدارتر در راستای اصول Agile و DevOps است.
#تست_نرمافزار #برنامهنویسی #کیفیت #DevOps #TDD #CI_CD #Agile #مهندسی_نرمافزار
🟣لینک مقاله:
https://cur.at/N39OqUZ?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Testing and Programming Are Not Separate Disciplines
🟢 خلاصه مقاله:
** این یادآوری از Ravisuriya Eswara تأکید میکند که توسعه و تست نرمافزار باید یک فرایند یکپارچه باشند، نه دو رشته جدا. با وارد کردن تست در متن کار روزانه—از تعریف معیارهای پذیرش و شناسایی ریسکها تا نوشتن تستها کنار کد، اجرای TDD و پایپلاینهای CI/CD—کیفیت از ابتدا طراحی میشود، نه در انتها ارزیابی.
این رویکرد مزایایی مانند کاهش نقیصههای تولید، بازخورد سریعتر، تحویل قابلپیشبینی، تجربه کاربری بهتر و هزینه نگهداری کمتر دارد. همکاری جایگزین تحویلهای مرحلهای میشود: توسعهدهندگان بر طراحیِ قابلتست تمرکز میکنند و تسترها با نگاه اکتشافی و کلنگر کیفیت را غنی میکنند؛ اتوماسیون و تست اکتشافی مکمل هماند. نتیجه، چرخهای سالمتر و محصولی پایدارتر در راستای اصول Agile و DevOps است.
#تست_نرمافزار #برنامهنویسی #کیفیت #DevOps #TDD #CI_CD #Agile #مهندسی_نرمافزار
🟣لینک مقاله:
https://cur.at/N39OqUZ?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Blogspot
Testing and Programming Are Not Separate Disciplines
Programming, Testing, Coding, Skills, Practice, Thinking, Debugging, Programming Languages, Data Structures, Tester, SDET, Developer, Myth
❤1
🔵 عنوان مقاله
Windows (GitHub Repo)
🟢 خلاصه مقاله:
** این GitHub Repo راهاندازی Windows داخل یک محیط Docker را ساده میکند: با دانلود خودکار ISO و بهرهگیری از شتابدهی KVM، یک ماشین مجازی Windows با کارایی نزدیک به بومی اجرا میشود. هدف، ارائه محیطی تکرارپذیر، قابلحمل و یکبارمصرف برای توسعه و تست است؛ با امکان دسترسی از راه دور (مثلاً RDP/VNC) و نگهداری دادهها از طریق volumeها. این راهحل برای CI/CD، تست میانسکویی و اجرای ابزارهای مخصوص Windows مفید است. نیازمندیها معمولاً شامل یک میزبان Linux با پشتیبانی KVM و رعایت الزامات لایسنس Windows است.
#Windows #Docker #KVM #Virtualization #DevOps #ISO #CloudNative #CI_CD
🟣لینک مقاله:
https://github.com/dockur/windows?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Windows (GitHub Repo)
🟢 خلاصه مقاله:
** این GitHub Repo راهاندازی Windows داخل یک محیط Docker را ساده میکند: با دانلود خودکار ISO و بهرهگیری از شتابدهی KVM، یک ماشین مجازی Windows با کارایی نزدیک به بومی اجرا میشود. هدف، ارائه محیطی تکرارپذیر، قابلحمل و یکبارمصرف برای توسعه و تست است؛ با امکان دسترسی از راه دور (مثلاً RDP/VNC) و نگهداری دادهها از طریق volumeها. این راهحل برای CI/CD، تست میانسکویی و اجرای ابزارهای مخصوص Windows مفید است. نیازمندیها معمولاً شامل یک میزبان Linux با پشتیبانی KVM و رعایت الزامات لایسنس Windows است.
#Windows #Docker #KVM #Virtualization #DevOps #ISO #CloudNative #CI_CD
🟣لینک مقاله:
https://github.com/dockur/windows?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
GitHub
GitHub - dockur/windows: Windows inside a Docker container.
Windows inside a Docker container. Contribute to dockur/windows development by creating an account on GitHub.
🤝1
🔵 عنوان مقاله
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
🔵 عنوان مقاله
Building Smarter Tests with Custom Annotations and Listeners in TestNG — A Practical Guide
🟢 خلاصه مقاله:
**این مقاله نشان میدهد چگونه با ترکیب annotationهای سفارشی و listenerها در TestNG میتوان تستهایی هوشمندتر، پایدارتر و مقیاسپذیرتر ساخت. با افزودن متادیتا مانند مالک، شدت، مؤلفه یا شرایط اجرا بهصورت annotation، اجرای تستها قابل کنترلتر میشود: فیلترکردن در CI، تنظیم داینامیک retry برای تستهای flaky، اعمال timeout و skipهای شرطی—all بدون شلوغکردن بدنه تستها. در سوی دیگر، listenerها از رویدادهای چرخه عمر TestNG برای لاگگیری یکدست، ثبت اسکرینشات و آرتیفکت در خطا، جمعآوری متریک زمان، قرنطینهکردن تستهای flaky، fail-fast و یکپارچهسازی با گزارشدهیهایی مثل Allure استفاده میکنند؛ بنابراین کد تست تمیزتر و رفتار مقطعی یکپارچه میشود. مقاله همچنین نکات اجرای موازی را پوشش میدهد: پرهیز از state مشترک، استفاده از منابع thread-local (مثل WebDriver)، جداسازی داده و تنظیم timeout برای حفظ ایزولیشن و کاهش flakiness در مقیاس CI. جمعبندی توصیه میکند مجموعهای کوچک و شفاف از annotationها و یک listener عمومی بسازید که سیاستها را از روی متادیتا اعمال کند، از بازتاب کنترلشده و قابلآزمون بهره ببرد و بهتدریج قابلیتهای باارزش مثل لاگ منسجم، آرتیفکتهای خطا و retry هدفمند را اضافه کند. در پایان، Vaibhav Chavan نکات کلیدی و راهنمای تکمیلی Parallel Testing with TestNG را معرفی میکند.
#TestNG #JavaTesting #Annotations #Listeners #ParallelTesting #AutomationTesting #QA #CI/CD
🟣لینک مقاله:
https://cur.at/2uhpDOO?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Building Smarter Tests with Custom Annotations and Listeners in TestNG — A Practical Guide
🟢 خلاصه مقاله:
**این مقاله نشان میدهد چگونه با ترکیب annotationهای سفارشی و listenerها در TestNG میتوان تستهایی هوشمندتر، پایدارتر و مقیاسپذیرتر ساخت. با افزودن متادیتا مانند مالک، شدت، مؤلفه یا شرایط اجرا بهصورت annotation، اجرای تستها قابل کنترلتر میشود: فیلترکردن در CI، تنظیم داینامیک retry برای تستهای flaky، اعمال timeout و skipهای شرطی—all بدون شلوغکردن بدنه تستها. در سوی دیگر، listenerها از رویدادهای چرخه عمر TestNG برای لاگگیری یکدست، ثبت اسکرینشات و آرتیفکت در خطا، جمعآوری متریک زمان، قرنطینهکردن تستهای flaky، fail-fast و یکپارچهسازی با گزارشدهیهایی مثل Allure استفاده میکنند؛ بنابراین کد تست تمیزتر و رفتار مقطعی یکپارچه میشود. مقاله همچنین نکات اجرای موازی را پوشش میدهد: پرهیز از state مشترک، استفاده از منابع thread-local (مثل WebDriver)، جداسازی داده و تنظیم timeout برای حفظ ایزولیشن و کاهش flakiness در مقیاس CI. جمعبندی توصیه میکند مجموعهای کوچک و شفاف از annotationها و یک listener عمومی بسازید که سیاستها را از روی متادیتا اعمال کند، از بازتاب کنترلشده و قابلآزمون بهره ببرد و بهتدریج قابلیتهای باارزش مثل لاگ منسجم، آرتیفکتهای خطا و retry هدفمند را اضافه کند. در پایان، Vaibhav Chavan نکات کلیدی و راهنمای تکمیلی Parallel Testing with TestNG را معرفی میکند.
#TestNG #JavaTesting #Annotations #Listeners #ParallelTesting #AutomationTesting #QA #CI/CD
🟣لینک مقاله:
https://cur.at/2uhpDOO?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Building Smarter Tests with Custom Annotations and Listeners in TestNG — A Practical Guide
When we talk about TestNG, most of us immediately think of the @Test annotation. It’s simple, powerful, and gets the job done. But what if…
🔵 عنوان مقاله
trdl (GitHub Repo)
🟢 خلاصه مقاله:
خلاصهای متنباز به نام trdl با تمرکز بر «تحویل مطمئن» آخرین مرحلهی توزیع نرمافزار را امن میکند: رساندن بهروزرسانیها از Git به کاربر نهایی با کانالی قابلاعتماد و قابلراستیآزمایی. این راهکار با اتصال طبیعی به فرآیندهای مبتنی بر Git و ادغام در اتوماسیون انتشار، تضمین میکند آنچه نصب میشود همان چیزی است که نگهدارندگان منتشر کردهاند. با تکیه بر امضا و راستیآزمایی رمزنگاری، اصالت، تمامیت و مبدأ بهروزرسانیها قبل از اعمال بررسی میشود؛ در نتیجه ریسکهای زنجیره تأمین کاهش مییابد و امکان انتشارهای قابلممیزی، بازگشت نسخه و سیاستهای بهروزرسانی (مانند stable یا pre-release) فراهم میشود. trdl متنباز است، میتواند self-hosted اجرا شود، و از طریق GitHub Repo در دسترس است؛ کاربران و تیمهای عملیاتی نیز میتوانند با یک رابط ساده مانند CLI بهروزرسانیهای مورد اعتماد را دریافت و اعمال کنند.
#trdl #SupplyChainSecurity #SecureUpdates #Git #OpenSource #DevOps #SoftwareDelivery #CI/CD
🟣لینک مقاله:
https://github.com/werf/trdl?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
trdl (GitHub Repo)
🟢 خلاصه مقاله:
خلاصهای متنباز به نام trdl با تمرکز بر «تحویل مطمئن» آخرین مرحلهی توزیع نرمافزار را امن میکند: رساندن بهروزرسانیها از Git به کاربر نهایی با کانالی قابلاعتماد و قابلراستیآزمایی. این راهکار با اتصال طبیعی به فرآیندهای مبتنی بر Git و ادغام در اتوماسیون انتشار، تضمین میکند آنچه نصب میشود همان چیزی است که نگهدارندگان منتشر کردهاند. با تکیه بر امضا و راستیآزمایی رمزنگاری، اصالت، تمامیت و مبدأ بهروزرسانیها قبل از اعمال بررسی میشود؛ در نتیجه ریسکهای زنجیره تأمین کاهش مییابد و امکان انتشارهای قابلممیزی، بازگشت نسخه و سیاستهای بهروزرسانی (مانند stable یا pre-release) فراهم میشود. trdl متنباز است، میتواند self-hosted اجرا شود، و از طریق GitHub Repo در دسترس است؛ کاربران و تیمهای عملیاتی نیز میتوانند با یک رابط ساده مانند CLI بهروزرسانیهای مورد اعتماد را دریافت و اعمال کنند.
#trdl #SupplyChainSecurity #SecureUpdates #Git #OpenSource #DevOps #SoftwareDelivery #CI/CD
🟣لینک مقاله:
https://github.com/werf/trdl?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
GitHub
GitHub - werf/trdl: The universal solution for delivering your software updates securely from a trusted The Update Framework (TUF)…
The universal solution for delivering your software updates securely from a trusted The Update Framework (TUF) repository. - werf/trdl
🔵 عنوان مقاله
In Sprint Test Automation
🟢 خلاصه مقاله:
در آزمونسازی دروناسپرینت در Agile، هدف این است که تستها همزمان با توسعه نوشته و اجرا شوند تا بازخورد سریع و خطاهای انباشته کاهش یابد. تجربهها نشان میدهد موفقیت به چند عامل وابسته است: خرد کردن قصهها به قطعات کوچک و قابلآزمون، پذیرش «Definition of Ready» و «Definition of Done» که شامل آزمون خودکار است، همکاری نزدیک Dev و QA با رویکردهای TDD/BDD، و برخورد با تست مثل کد (همان مخزن، همان استراتژی شاخه، همان بازبینی کد).
برای پشتیبانی از این جریان، CI/CD باید سریع و قابلاعتماد باشد: اجرای موازی، محیطهای موقتی مبتنی بر کانتینر، مجازیسازی سرویسها و Mockها برای قطع وابستگیها، و مدیریت دادهی تست که آزمونها را تکرارپذیر و بدون نوسان نگه میدارد. تمرکز بر هرم تست ضروری است: پوشش بالای Unit و Integration/Contract، و تنها یک لایه نازک از E2E UI (مثلاً با Cypress یا Playwright)؛ در کنار آن، سنجههایی مانند زمان رسیدن تغییر تا استقرار، نرخ شکست و زمان ترمیم رصد میشوند و تستهای flaky سریع قرنطینه و اصلاح میگردند.
همچنین پرهیز از الگوهای ضدِکیفیت مانند «Hardening Sprint»، عقبانداختن اتوماسیون بهعنوان بدهی، یا اتکا به E2E شکننده توصیه میشود. استفاده از Feature Flag، Contract Testing در معماریهای مبتنی بر سرویس، و مالکیت مشترک کیفیت در کل تیم به تحقق «اتمام واقعی کار» در همان اسپرینت کمک میکند.
#Agile #TestAutomation #InSprintTesting #CI_CD #TDD #BDD #DevOps
🟣لینک مقاله:
https://cur.at/46VanjF?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
In Sprint Test Automation
🟢 خلاصه مقاله:
در آزمونسازی دروناسپرینت در Agile، هدف این است که تستها همزمان با توسعه نوشته و اجرا شوند تا بازخورد سریع و خطاهای انباشته کاهش یابد. تجربهها نشان میدهد موفقیت به چند عامل وابسته است: خرد کردن قصهها به قطعات کوچک و قابلآزمون، پذیرش «Definition of Ready» و «Definition of Done» که شامل آزمون خودکار است، همکاری نزدیک Dev و QA با رویکردهای TDD/BDD، و برخورد با تست مثل کد (همان مخزن، همان استراتژی شاخه، همان بازبینی کد).
برای پشتیبانی از این جریان، CI/CD باید سریع و قابلاعتماد باشد: اجرای موازی، محیطهای موقتی مبتنی بر کانتینر، مجازیسازی سرویسها و Mockها برای قطع وابستگیها، و مدیریت دادهی تست که آزمونها را تکرارپذیر و بدون نوسان نگه میدارد. تمرکز بر هرم تست ضروری است: پوشش بالای Unit و Integration/Contract، و تنها یک لایه نازک از E2E UI (مثلاً با Cypress یا Playwright)؛ در کنار آن، سنجههایی مانند زمان رسیدن تغییر تا استقرار، نرخ شکست و زمان ترمیم رصد میشوند و تستهای flaky سریع قرنطینه و اصلاح میگردند.
همچنین پرهیز از الگوهای ضدِکیفیت مانند «Hardening Sprint»، عقبانداختن اتوماسیون بهعنوان بدهی، یا اتکا به E2E شکننده توصیه میشود. استفاده از Feature Flag، Contract Testing در معماریهای مبتنی بر سرویس، و مالکیت مشترک کیفیت در کل تیم به تحقق «اتمام واقعی کار» در همان اسپرینت کمک میکند.
#Agile #TestAutomation #InSprintTesting #CI_CD #TDD #BDD #DevOps
🟣لینک مقاله:
https://cur.at/46VanjF?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Reddit
From the QualityAssurance community on Reddit
Explore this post and more from the QualityAssurance community
👍1
🔵 عنوان مقاله
How to Test Asynchronous Processes That Complete Hours Later
🟢 خلاصه مقاله:
** دانیل Delimata نشان میدهد چگونه با بازطراحی کوچک در سیستم و تستها میتوان فرایندهای ناهمگامی را که نتیجهشان ساعتها بعد دیده میشود، بهصورت خودکار و سریع راستیآزمایی کرد. رویکرد پیشنهادی بر «assertionهای در نهایت» با مهلت مشخص تکیه دارد: بهجای sleep طولانی، رویداد را آغاز کنید و با polling یا اشتراک در خروجیها (داده، رویداد، ایمیل) نتیجه را تا ضربالاجل تعیینشده بررسی کنید. زمان را تزریقپذیر کنید (clock فیک)، زمانبندیها را قابلپیکربندی کنید یا test hook امن برای اجرای فوری کارها فراهم کنید؛ و با شناسههای همبستگی و مشاهدهپذیری (مثل OpenTelemetry) مسیر انتهابهانتها را رهگیری کنید. برای پایداری، هندلرهای idempotent، دادهی تست ایزوله و محیطهای موقتی به کار ببرید و سطح مناسب تست (واحد، یکپارچه، انتهابهانتها، contract) را انتخاب کنید. در CI، مسیر سریع با زمان شتابداده/هوک و مسیر آهسته شبانهی واقعگرایانه را ترکیب کنید تا فرایندهایی که ساعتها طول میکشند، در چند دقیقه بهطور مطمئن تست شوند.
#AsynchronousTesting #EventualConsistency #Automation #DistributedSystems #E2ETesting #Observability #CI_CD #MessageQueues
🟣لینک مقاله:
https://cur.at/tVLKSEQ?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How to Test Asynchronous Processes That Complete Hours Later
🟢 خلاصه مقاله:
** دانیل Delimata نشان میدهد چگونه با بازطراحی کوچک در سیستم و تستها میتوان فرایندهای ناهمگامی را که نتیجهشان ساعتها بعد دیده میشود، بهصورت خودکار و سریع راستیآزمایی کرد. رویکرد پیشنهادی بر «assertionهای در نهایت» با مهلت مشخص تکیه دارد: بهجای sleep طولانی، رویداد را آغاز کنید و با polling یا اشتراک در خروجیها (داده، رویداد، ایمیل) نتیجه را تا ضربالاجل تعیینشده بررسی کنید. زمان را تزریقپذیر کنید (clock فیک)، زمانبندیها را قابلپیکربندی کنید یا test hook امن برای اجرای فوری کارها فراهم کنید؛ و با شناسههای همبستگی و مشاهدهپذیری (مثل OpenTelemetry) مسیر انتهابهانتها را رهگیری کنید. برای پایداری، هندلرهای idempotent، دادهی تست ایزوله و محیطهای موقتی به کار ببرید و سطح مناسب تست (واحد، یکپارچه، انتهابهانتها، contract) را انتخاب کنید. در CI، مسیر سریع با زمان شتابداده/هوک و مسیر آهسته شبانهی واقعگرایانه را ترکیب کنید تا فرایندهایی که ساعتها طول میکشند، در چند دقیقه بهطور مطمئن تست شوند.
#AsynchronousTesting #EventualConsistency #Automation #DistributedSystems #E2ETesting #Observability #CI_CD #MessageQueues
🟣لینک مقاله:
https://cur.at/tVLKSEQ?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
How to Test Asynchronous Processes That Complete Hours Later
In most automated tests, we expect systems to react immediately: send a request → get a response → verify the result.
🔵 عنوان مقاله
Every Bug Deserves a Test Case
🟢 خلاصه مقاله:
ایده اصلی این است که هر باگ پس از برطرفشدن باید با یک تست اختصاصی پوشش داده شود. بهگفتهی Kevin Konda، برای هر باگ ابتدا یک تست بازتولیدکننده بنویسید، شکست آن را ببینید، مشکل را رفع کنید و سپس همان تستِ سبز را در مجموعهی رگرسیون نگه دارید. این کار از بازگشت خطاها جلوگیری میکند، دانشِ لبههای پنهان را حفظ میکند، ریسکیبودن تغییرات را کاهش میدهد و به بهبود طراحی کمک میکند. با نامگذاری شفاف، پیوند به شناسهی Issue، کوچکوساده نگهداشتن تستها و تفکیک اجرای سریع و شبانه، میتوان هزینهی زمان و ناپایداری را کنترل کرد. در نهایت، «هر باگ یک تست» یک انضباط فرهنگی است: اشتباهات گذشته را به ریلهای محافظ آینده تبدیل کنید.
#SoftwareTesting #RegressionTesting #QualityEngineering #TDD #BugFixing #TestCoverage #CI #EngineeringCulture
🟣لینک مقاله:
https://cur.at/Kvqi6KW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Every Bug Deserves a Test Case
🟢 خلاصه مقاله:
ایده اصلی این است که هر باگ پس از برطرفشدن باید با یک تست اختصاصی پوشش داده شود. بهگفتهی Kevin Konda، برای هر باگ ابتدا یک تست بازتولیدکننده بنویسید، شکست آن را ببینید، مشکل را رفع کنید و سپس همان تستِ سبز را در مجموعهی رگرسیون نگه دارید. این کار از بازگشت خطاها جلوگیری میکند، دانشِ لبههای پنهان را حفظ میکند، ریسکیبودن تغییرات را کاهش میدهد و به بهبود طراحی کمک میکند. با نامگذاری شفاف، پیوند به شناسهی Issue، کوچکوساده نگهداشتن تستها و تفکیک اجرای سریع و شبانه، میتوان هزینهی زمان و ناپایداری را کنترل کرد. در نهایت، «هر باگ یک تست» یک انضباط فرهنگی است: اشتباهات گذشته را به ریلهای محافظ آینده تبدیل کنید.
#SoftwareTesting #RegressionTesting #QualityEngineering #TDD #BugFixing #TestCoverage #CI #EngineeringCulture
🟣لینک مقاله:
https://cur.at/Kvqi6KW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Every Bug Deserves a Test Case
Why adding bug-based test cases to your master suite makes your QA smarter, stronger, and future-ready.
🔵 عنوان مقاله
Running Lighthouse CI in a Lightweight Docker Container
🟢 خلاصه مقاله:
**این مطلب نشان میدهد چگونه میتوان Lighthouse CI را در یک Docker کانتینر سبک اجرا کرد تا سنجش عملکرد وباپها بهصورت خودکار و قابلاتکا در CI انجام شود. ایده اصلی، ساخت یک ایمیج کوچک (مثلاً بر پایه Alpine + Node) با CLI مربوط به Lighthouse CI و یک Chromium هدلس است تا روی GitHub Actions، GitLab CI، یا CircleCI کاملاً یکسان عمل کند و زمان راهاندازی و هزینههای CI را پایین نگه دارد. در خط لوله، پس از build و serve کردن برنامه (یا هدفگیری یک URL مستقر)، کانتینر اجرا میشود، معیارهایی مانند LCP، CLS و TBT را استخراج میکند، گزارشهای HTML/JSON تولید میکند، و با baseline و بودجههای عملکردی مقایسه میکند تا در صورت عقبگرد یا عبور از آستانهها، build را fail کند. برای پایداری نتایج، باید شبکه و CPU را شبیهسازی (throttle) کرد، cacheها را بین اجراها نگه داشت، بهصورت non-root اجرا شد و تنها در صورت نیاز از پرچمهایی مثل no-sandbox استفاده کرد. این چیدمان بهراحتی در PRها برای gate کردن mergeها و نیز در اجرای شبانه روی محیط production قابل استفاده است و در نهایت یک سازوکار سبک، تکرارپذیر و کمهزینه برای کنترل دائمی عملکرد ارائه میدهد.
#Lighthouse #LighthouseCI #Docker #WebPerformance #CI #DevOps #PerformanceBudgets #ContinuousIntegration
🟣لینک مقاله:
https://cur.at/ghYEsiF?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Running Lighthouse CI in a Lightweight Docker Container
🟢 خلاصه مقاله:
**این مطلب نشان میدهد چگونه میتوان Lighthouse CI را در یک Docker کانتینر سبک اجرا کرد تا سنجش عملکرد وباپها بهصورت خودکار و قابلاتکا در CI انجام شود. ایده اصلی، ساخت یک ایمیج کوچک (مثلاً بر پایه Alpine + Node) با CLI مربوط به Lighthouse CI و یک Chromium هدلس است تا روی GitHub Actions، GitLab CI، یا CircleCI کاملاً یکسان عمل کند و زمان راهاندازی و هزینههای CI را پایین نگه دارد. در خط لوله، پس از build و serve کردن برنامه (یا هدفگیری یک URL مستقر)، کانتینر اجرا میشود، معیارهایی مانند LCP، CLS و TBT را استخراج میکند، گزارشهای HTML/JSON تولید میکند، و با baseline و بودجههای عملکردی مقایسه میکند تا در صورت عقبگرد یا عبور از آستانهها، build را fail کند. برای پایداری نتایج، باید شبکه و CPU را شبیهسازی (throttle) کرد، cacheها را بین اجراها نگه داشت، بهصورت non-root اجرا شد و تنها در صورت نیاز از پرچمهایی مثل no-sandbox استفاده کرد. این چیدمان بهراحتی در PRها برای gate کردن mergeها و نیز در اجرای شبانه روی محیط production قابل استفاده است و در نهایت یک سازوکار سبک، تکرارپذیر و کمهزینه برای کنترل دائمی عملکرد ارائه میدهد.
#Lighthouse #LighthouseCI #Docker #WebPerformance #CI #DevOps #PerformanceBudgets #ContinuousIntegration
🟣لینک مقاله:
https://cur.at/ghYEsiF?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Running Lighthouse CI in a Lightweight Docker Container
This guide demonstrates how to run Lighthouse CI performance tests for www.pradappandiyan.com using a lightweight Docker container. By…
🔵 عنوان مقاله
Architecture Tests
🟢 خلاصه مقاله:
** تاراس Kizlo در ادامهٔ مجموعهٔ خود دربارهٔ سطوح تست، سراغ موضوع کمتر مطرحشدهای رفته است: تستهای معماری. او توضیح میدهد که این تستها مجموعهای از قواعد اجراییاند که مرزهای معماری، وابستگیهای مجاز، نبود حلقههای وابستگی و قواعد نامگذاری/لایهبندی را بررسی میکنند تا از فرسایش تدریجی طراحی جلوگیری شود. مقاله نشان میدهد چگونه میتوان این قواعد را کنار تستهای معمول و در CI/CD اجرا کرد و با ابزارهایی مثل ArchUnit یا NetArchTest آنها را به شکستپذیر کردن بیلد گره زد. توصیههای عملی شامل شروع از چند قانون پرتأثیر، پرهیز از قواعد شکننده، همگامسازی با تصمیمهای معماری و بهروزرسانی مداوم تستهاست. نتیجهٔ نهایی: تستهای معماری قصد طراحی را به قراردادهای قابل اجرا تبدیل میکنند و بهعنوان گاردریلهای ماندگار، ساختار سالم کد را حفظ میکنند.
#ArchitectureTests #SoftwareArchitecture #SoftwareTesting #CleanArchitecture #CI/CD #ArchUnit #NetArchTest #CodeQuality
🟣لینک مقاله:
https://cur.at/WG4foAM?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Architecture Tests
🟢 خلاصه مقاله:
** تاراس Kizlo در ادامهٔ مجموعهٔ خود دربارهٔ سطوح تست، سراغ موضوع کمتر مطرحشدهای رفته است: تستهای معماری. او توضیح میدهد که این تستها مجموعهای از قواعد اجراییاند که مرزهای معماری، وابستگیهای مجاز، نبود حلقههای وابستگی و قواعد نامگذاری/لایهبندی را بررسی میکنند تا از فرسایش تدریجی طراحی جلوگیری شود. مقاله نشان میدهد چگونه میتوان این قواعد را کنار تستهای معمول و در CI/CD اجرا کرد و با ابزارهایی مثل ArchUnit یا NetArchTest آنها را به شکستپذیر کردن بیلد گره زد. توصیههای عملی شامل شروع از چند قانون پرتأثیر، پرهیز از قواعد شکننده، همگامسازی با تصمیمهای معماری و بهروزرسانی مداوم تستهاست. نتیجهٔ نهایی: تستهای معماری قصد طراحی را به قراردادهای قابل اجرا تبدیل میکنند و بهعنوان گاردریلهای ماندگار، ساختار سالم کد را حفظ میکنند.
#ArchitectureTests #SoftwareArchitecture #SoftwareTesting #CleanArchitecture #CI/CD #ArchUnit #NetArchTest #CodeQuality
🟣لینک مقاله:
https://cur.at/WG4foAM?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Architecture Tests
Architecture tests are an essential part of maintaining a healthy architecture. First time hearing? No worries, we will explore what those…
🔵 عنوان مقاله
Our Journey Through Optimising Cypress End-to-End Tests
🟢 خلاصه مقاله:
** این مقاله به قلم Omer Keskinkilic مجموعهای از تجربههای عملی برای بهینهسازی تستهای انتهابهانتها با Cypress ارائه میکند. محورها سهگانهاند: طراحی درست تست، افزایش سرعت اجرا و نگهداری بلندمدت.
در طراحی، تمرکز بر پایداری و خوانایی است: استفاده از selectorهای پایدار مانند data-test، کوچک و متمرکز نگهداشتن سناریوها، استخراج گامهای تکراری به custom commandها و پرهیز از waitهای دلخواه با همگامسازی قطعی مبتنی بر وضعیت.
برای سرعت، توصیهها شامل استفاده هدفمند از cy.intercept برای stub کردن ضروری، seed کردن داده، میانبر زدن ورود با cy.session، تقسیم مجموعه به smoke و full، موازیسازی در CI با Cypress Dashboard، اجرای headless و کش وابستگیها و محدود کردن خروجیها به شکستهاست.
در نگهداری، ساختار پوشه و نامگذاری یکدست، کمکهزینههای DRY بهجای page objectهای سنگین، مدیریت سریع flakyها (با retry بهعنوان چاره موقت)، استفاده از TypeScript برای اطمینان بیشتر در utilityها و commandها، و پیکربندی محیط از طریق cypress.config.js و متغیرهای محیطی پیشنهاد میشود. با اجرای تدریجی این نکات، مجموعه تستهای Cypress پایدارتر، سریعتر و قابل اتکاتر میشود.
#Cypress #E2E #TestAutomation #QA #JavaScript #CI #CypressDashboard #Performance
🟣لینک مقاله:
https://cur.at/YjuFkp3?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Our Journey Through Optimising Cypress End-to-End Tests
🟢 خلاصه مقاله:
** این مقاله به قلم Omer Keskinkilic مجموعهای از تجربههای عملی برای بهینهسازی تستهای انتهابهانتها با Cypress ارائه میکند. محورها سهگانهاند: طراحی درست تست، افزایش سرعت اجرا و نگهداری بلندمدت.
در طراحی، تمرکز بر پایداری و خوانایی است: استفاده از selectorهای پایدار مانند data-test، کوچک و متمرکز نگهداشتن سناریوها، استخراج گامهای تکراری به custom commandها و پرهیز از waitهای دلخواه با همگامسازی قطعی مبتنی بر وضعیت.
برای سرعت، توصیهها شامل استفاده هدفمند از cy.intercept برای stub کردن ضروری، seed کردن داده، میانبر زدن ورود با cy.session، تقسیم مجموعه به smoke و full، موازیسازی در CI با Cypress Dashboard، اجرای headless و کش وابستگیها و محدود کردن خروجیها به شکستهاست.
در نگهداری، ساختار پوشه و نامگذاری یکدست، کمکهزینههای DRY بهجای page objectهای سنگین، مدیریت سریع flakyها (با retry بهعنوان چاره موقت)، استفاده از TypeScript برای اطمینان بیشتر در utilityها و commandها، و پیکربندی محیط از طریق cypress.config.js و متغیرهای محیطی پیشنهاد میشود. با اجرای تدریجی این نکات، مجموعه تستهای Cypress پایدارتر، سریعتر و قابل اتکاتر میشود.
#Cypress #E2E #TestAutomation #QA #JavaScript #CI #CypressDashboard #Performance
🟣لینک مقاله:
https://cur.at/YjuFkp3?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Our Journey Through Optimising Cypress End-to-End Tests
The purpose of automated tests is not to find bugs. It’s to give you confidence to make changes. — Gojko Adžić