🔵 عنوان مقاله
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