🔵 عنوان مقاله
From Templates to Heuristics: Enhancing Thought Work
🟢 خلاصه مقاله:
تست مؤثر بیش از آن‌که به پر کردن قالب‌ها و چک‌لیست‌ها تکیه کند، به فهم عمیق و تأمل وابسته است. Maria Kedemo تأکید می‌کند که به‌جای تمرکز بر فرم‌ها، باید با نگاه انتقادی و زمینه‌محور به ریسک و ارزش فکر کنیم. در این رویکرد، هیوریستیک‌ها (heuristics) به‌عنوان راهنماهای منعطف و خطاپذیر به ما کمک می‌کنند پرسش‌های بهتری بپرسیم، فرضیات پنهان را آشکار کنیم و بر اساس چرخه‌های مشاهده، فرضیه‌سازی، آزمون و یادگیری مسیر را تنظیم کنیم. سازمان‌ها باید زمان و سازوکارهایی برای بازاندیشی (مثل دی‌بریف و بازبینی همتا) فراهم کنند و موفقیت را با کیفیت اطلاعات ریسکی و یادگیری حاصل بسنجند، نه با تعداد موارد آزمون یا فرم‌های تکمیل‌شده. قالب‌ها می‌توانند نقش داربست داشته باشند، اما مقصد نیستند؛ مقصد، اندیشیدن بهتر و تصمیم‌های سازگار با زمینه است.
#SoftwareTesting #Heuristics #ExploratoryTesting #QualityEngineering #TestingStrategy #CriticalThinking #ContextDrivenTesting
🟣لینک مقاله:
https://cur.at/Q0yh9ik?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
From Templates to Heuristics: Enhancing Thought Work
🟢 خلاصه مقاله:
تست مؤثر بیش از آن‌که به پر کردن قالب‌ها و چک‌لیست‌ها تکیه کند، به فهم عمیق و تأمل وابسته است. Maria Kedemo تأکید می‌کند که به‌جای تمرکز بر فرم‌ها، باید با نگاه انتقادی و زمینه‌محور به ریسک و ارزش فکر کنیم. در این رویکرد، هیوریستیک‌ها (heuristics) به‌عنوان راهنماهای منعطف و خطاپذیر به ما کمک می‌کنند پرسش‌های بهتری بپرسیم، فرضیات پنهان را آشکار کنیم و بر اساس چرخه‌های مشاهده، فرضیه‌سازی، آزمون و یادگیری مسیر را تنظیم کنیم. سازمان‌ها باید زمان و سازوکارهایی برای بازاندیشی (مثل دی‌بریف و بازبینی همتا) فراهم کنند و موفقیت را با کیفیت اطلاعات ریسکی و یادگیری حاصل بسنجند، نه با تعداد موارد آزمون یا فرم‌های تکمیل‌شده. قالب‌ها می‌توانند نقش داربست داشته باشند، اما مقصد نیستند؛ مقصد، اندیشیدن بهتر و تصمیم‌های سازگار با زمینه است.
#SoftwareTesting #Heuristics #ExploratoryTesting #QualityEngineering #TestingStrategy #CriticalThinking #ContextDrivenTesting
🟣لینک مقاله:
https://cur.at/Q0yh9ik?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Curiousity killed the cat
From Templates to Heuristics: Enhancing Thought Work
Update 2025-10-14: This post has been updated to reflect thought work rather than knowledge work – which was pointed out by Fiona Charles as a much better description of the cognitive work pe…
🔵 عنوان مقاله
Dismantling a Critical Supply Chain Risk in VSCode Extension Marketplaces (7 minute read)
🟢 خلاصه مقاله:
بیش از ۵۵۰ راز حساس در افزونه‌های عمومی VSCode افشا شد، از جمله AWS و GitHub tokens. علت اصلی، مدیریت ناامن فایل‌ها در فرایند توسعه و انتشار بود؛ مشکلی که می‌تواند به مهاجمان امکان دهد با سوءاستفاده از توکن‌ها به‌روزرسانی‌های مخرب منتشر کنند و حملات زنجیره‌تأمین را آغاز کنند. در واکنش، پلتفرم‌ها توکن‌های آسیب‌دیده را باطل کردند، ناشران را مطلع ساختند و اسکن خودکار را تقویت کردند. این حادثه بر ضرورت ایمن‌سازی اکوسیستم افزونه‌ها تأکید دارد: حذف فایل‌های حساس از بسته‌ها، استفاده از secret managers به‌جای درج مستقیم کلیدها، محدود کردن سطح دسترسی توکن‌ها، و اسکن مداوم برای کشف نشت رازها.
#SupplyChainSecurity #VSCode #DevSecOps #SecretsManagement #AppSec #TokenSecurity #SoftwareSupplyChain #SecureCoding
🟣لینک مقاله:
https://www.wiz.io/blog/supply-chain-risk-in-vscode-extension-marketplaces?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Dismantling a Critical Supply Chain Risk in VSCode Extension Marketplaces (7 minute read)
🟢 خلاصه مقاله:
بیش از ۵۵۰ راز حساس در افزونه‌های عمومی VSCode افشا شد، از جمله AWS و GitHub tokens. علت اصلی، مدیریت ناامن فایل‌ها در فرایند توسعه و انتشار بود؛ مشکلی که می‌تواند به مهاجمان امکان دهد با سوءاستفاده از توکن‌ها به‌روزرسانی‌های مخرب منتشر کنند و حملات زنجیره‌تأمین را آغاز کنند. در واکنش، پلتفرم‌ها توکن‌های آسیب‌دیده را باطل کردند، ناشران را مطلع ساختند و اسکن خودکار را تقویت کردند. این حادثه بر ضرورت ایمن‌سازی اکوسیستم افزونه‌ها تأکید دارد: حذف فایل‌های حساس از بسته‌ها، استفاده از secret managers به‌جای درج مستقیم کلیدها، محدود کردن سطح دسترسی توکن‌ها، و اسکن مداوم برای کشف نشت رازها.
#SupplyChainSecurity #VSCode #DevSecOps #SecretsManagement #AppSec #TokenSecurity #SoftwareSupplyChain #SecureCoding
🟣لینک مقاله:
https://www.wiz.io/blog/supply-chain-risk-in-vscode-extension-marketplaces?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
wiz.io
Supply Chain Risk in VSCode Extension Marketplaces | Wiz Blog
Wiz Research uncovered 500+ leaked secrets in VSCode and Open VSX extensions, exposing 150K installs to risk. Learn what happened and how it was fixed.
🔵 عنوان مقاله
Power pairing our people process: How we moved to a collaborative QA Engineer and QA Analyst model
🟢 خلاصه مقاله:
** این مقاله نشان میدهد که با جفت‌کردن نقشهای مکمل در کیفیت، یعنی QA Engineer و QA Analyst، می‌توان کیفیت را از یک مرحله انتهایی به یک فعالیت پیوسته و مشارکتی در دل فرایند توسعه تبدیل کرد. بر اساس ایده‌های Matthew Whitaker و همسو با فلسفه pair-programming، QA Engineer روی اتوماسیون، ابزارها و CI/CD تمرکز می‌کند و QA Analyst بر تحلیل نیازمندی‌ها، آزمون اکتشافی و مدیریت ریسک؛ و همکاری نزدیک آن‌ها شکاف‌های فنی و محصولی را کاهش میدهد. این جفت به‌صورت مشترک معیارهای پذیرش و استراتژی آزمون را می‌نویسد، بین نقش «راننده/راهنما» جابه‌جا می‌شود و یافته‌های اکتشافی را سریع به تست‌های خودکار قابل نگهداری تبدیل می‌کند. پیاده‌سازی موفق با یک پایلوت، برنامه pairing شفاف، ابزارهای دیدپذیری، و سنجه‌هایی مانند نرخ خطای فرار، زمان چرخه و نرخ بازکار آغاز می‌شود و با مدیریت چالش‌هایی مانند ابهام نقش و خستگی جلسات از طریق RACI سبک، پلی‌بوک، تایم‌باکس و آداب pairing تثبیت می‌شود. دستاوردها شامل بازخورد سریع‌تر، کاهش خطاهای فرار، مالکیت مشترک کیفیت و انتقال دانش گسترده‌تر در تیم است؛ همان درسی که از pair-programming می‌گیریم: دو ذهن مکمل، از یک متخصص تنها مؤثرترند.
#QA #PairProgramming #QualityAssurance #AgileTesting #Collaboration #DevOps #TestAutomation #TeamCulture
🟣لینک مقاله:
https://cur.at/EuZObTr?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Power pairing our people process: How we moved to a collaborative QA Engineer and QA Analyst model
🟢 خلاصه مقاله:
** این مقاله نشان میدهد که با جفت‌کردن نقشهای مکمل در کیفیت، یعنی QA Engineer و QA Analyst، می‌توان کیفیت را از یک مرحله انتهایی به یک فعالیت پیوسته و مشارکتی در دل فرایند توسعه تبدیل کرد. بر اساس ایده‌های Matthew Whitaker و همسو با فلسفه pair-programming، QA Engineer روی اتوماسیون، ابزارها و CI/CD تمرکز می‌کند و QA Analyst بر تحلیل نیازمندی‌ها، آزمون اکتشافی و مدیریت ریسک؛ و همکاری نزدیک آن‌ها شکاف‌های فنی و محصولی را کاهش میدهد. این جفت به‌صورت مشترک معیارهای پذیرش و استراتژی آزمون را می‌نویسد، بین نقش «راننده/راهنما» جابه‌جا می‌شود و یافته‌های اکتشافی را سریع به تست‌های خودکار قابل نگهداری تبدیل می‌کند. پیاده‌سازی موفق با یک پایلوت، برنامه pairing شفاف، ابزارهای دیدپذیری، و سنجه‌هایی مانند نرخ خطای فرار، زمان چرخه و نرخ بازکار آغاز می‌شود و با مدیریت چالش‌هایی مانند ابهام نقش و خستگی جلسات از طریق RACI سبک، پلی‌بوک، تایم‌باکس و آداب pairing تثبیت می‌شود. دستاوردها شامل بازخورد سریع‌تر، کاهش خطاهای فرار، مالکیت مشترک کیفیت و انتقال دانش گسترده‌تر در تیم است؛ همان درسی که از pair-programming می‌گیریم: دو ذهن مکمل، از یک متخصص تنها مؤثرترند.
#QA #PairProgramming #QualityAssurance #AgileTesting #Collaboration #DevOps #TestAutomation #TeamCulture
🟣لینک مقاله:
https://cur.at/EuZObTr?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Ministry of Testing
Power pairing our people process: How we moved to a collaborative QA Engineer and QA Analyst model
Pairing QA Engineers and Analysts isn't just a process tweak, it's a cultural shift that transforms siloed testing into a collaborative, balanced and business-aligned effort.
تفاوت Access Token و Refresh Token به زبان ساده
در سیستم‌های احراز هویت مدرن مثل Keycloak یا IdentityServer،
دوبار اسم «توکن» رو می‌شنویم:
ولی واقعاً فرقشون چیه؟
Access Token
توکن کوتاه‌مدتیه (مثلاً ۵ تا ۱۵ دقیقه) که بعد از لاگین کاربر صادر میشه.
هر بار که کاربر به API درخواست می‌فرسته، این توکن همراه درخواست میره تا سرور بفهمه کاربر کیه.
Refresh Token
طول عمر بیشتری داره (مثلاً ۳۰ دقیقه یا حتی چند ساعت).
اگر Access Token منقضی بشه، سیستم با استفاده از Refresh Token یه Access Token جدید می‌گیره
— بدون اینکه کاربر مجبور باشه دوباره لاگین کنه.
به زبان ساده Access Token مثل بلیط ورود به یک سالن هست ️
اما Refresh Token مثل کارت عضویت اون سالنه
باهاش می‌تونی هر بار بلیط جدید بگیری بدون ایستادن تو صف لاگین.
مزیت این روش:
امنیت بیشتر (Access Token کوتاه‌مدت و ایمن‌تره)
تجربه کاربری بهتر (کاربر کمتر لاگ‌اوت میشه)
کنترل بهتر سمت سرور روی اعتبار توکن‌ها
در پروژه‌ی اخیرم با Keycloak این مکانیزم رو پیاده‌سازی کردم.
کاربر بعد از ثبت‌نام، هم در Keycloak و هم در SQL Server ذخیره میشه تا
میان سیستم احراز هویت و اپلیکیشن اصلی یکپارچگی کامل برقرار باشه.
هر وقت در مورد Authentication کار می‌کنی،
یادت باشه که هدف فقط «ورود کاربر» نیست —
بلکه «مدیریت ایمن و هوشمند عمر نشست (Session Lifecycle)» هست.
در دنیای Api ها ما موظفیم با توکن ها کار کنیم
در ریزور پیج ها یک ورودی هیدن داشتیم که مدیریت توسط آن توسط خود asp بود
اما در api ها مدیریت توکن ها با ماست
بهترین گزینه هم استفاده از IDP (Identity Provider) هاست چون هم فرانت و هم بک را برای ما پوشش میدهد.
<Hossein Molaei/>
در سیستم‌های احراز هویت مدرن مثل Keycloak یا IdentityServer،
دوبار اسم «توکن» رو می‌شنویم:
ولی واقعاً فرقشون چیه؟
Access Token
توکن کوتاه‌مدتیه (مثلاً ۵ تا ۱۵ دقیقه) که بعد از لاگین کاربر صادر میشه.
هر بار که کاربر به API درخواست می‌فرسته، این توکن همراه درخواست میره تا سرور بفهمه کاربر کیه.
Refresh Token
طول عمر بیشتری داره (مثلاً ۳۰ دقیقه یا حتی چند ساعت).
اگر Access Token منقضی بشه، سیستم با استفاده از Refresh Token یه Access Token جدید می‌گیره
— بدون اینکه کاربر مجبور باشه دوباره لاگین کنه.
به زبان ساده Access Token مثل بلیط ورود به یک سالن هست ️
اما Refresh Token مثل کارت عضویت اون سالنه
باهاش می‌تونی هر بار بلیط جدید بگیری بدون ایستادن تو صف لاگین.
مزیت این روش:
امنیت بیشتر (Access Token کوتاه‌مدت و ایمن‌تره)
تجربه کاربری بهتر (کاربر کمتر لاگ‌اوت میشه)
کنترل بهتر سمت سرور روی اعتبار توکن‌ها
در پروژه‌ی اخیرم با Keycloak این مکانیزم رو پیاده‌سازی کردم.
کاربر بعد از ثبت‌نام، هم در Keycloak و هم در SQL Server ذخیره میشه تا
میان سیستم احراز هویت و اپلیکیشن اصلی یکپارچگی کامل برقرار باشه.
هر وقت در مورد Authentication کار می‌کنی،
یادت باشه که هدف فقط «ورود کاربر» نیست —
بلکه «مدیریت ایمن و هوشمند عمر نشست (Session Lifecycle)» هست.
در دنیای Api ها ما موظفیم با توکن ها کار کنیم
در ریزور پیج ها یک ورودی هیدن داشتیم که مدیریت توسط آن توسط خود asp بود
اما در api ها مدیریت توکن ها با ماست
بهترین گزینه هم استفاده از IDP (Identity Provider) هاست چون هم فرانت و هم بک را برای ما پوشش میدهد.
<Hossein Molaei/>
❤1
🔵 عنوان مقاله
When Tests Start Drawing the Map
🟢 خلاصه مقاله:
** در دنیای واقعی توسعه، محیط‌های تست به‌ندرت کامل‌اند: اطلاعات ناقص است، وابستگی‌ها تغییر می‌کنند و قطعیت کم است. Charlie Kingston پیشنهاد می‌کند به تست مثل «نقشه‌کش» نگاه کنیم؛ هر تست یک کاوش است که مرزها، خطرها و رفتارهای واقعی سیستم را روشن می‌کند و نقشهای زنده از آنچه می‌دانیم می‌سازد.
با بیان شفاف فرضیه‌ها و تبدیلشان به تست، استفاده از ابزارهـای مشاهده‌پذیری برای رفع نقاط کور، ایجاد چرخه‌های بازخورد سریع و اولویت‌بندی ریسک (مسیرهای بحرانی، حالت‌های خرابی، و درزهای یکپارچه‌سازی)، این نقشه قابل اعتماد می‌شود. تست‌ها فقط دروازه انتشار نیستند؛ دانسته‌های تیم را مستند می‌کنند، قراردادهای بین سرویس‌ها را شفاف می‌سازند و بازطراحی امن را ممکن می‌کنند. با هر تغییر، تست‌ها نشان می‌دهند کجا نقشه با واقعیت نمی‌خواند و باید دقیق‌تر بررسی شود.
ترکیبی از روش‌ها این نقشه را کامل‌تر می‌کند: Contract Testها برای انتظارات بین سرویس‌ها، Property-based Testing برای پوشش لبه‌ها، تست اکتشافی برای کشف ناشناخته‌ها، و پایش مصنوعی در محیط اجرا برای تشخیص تغییر رفتار. پیام نهایی: منتظر مشخصات کامل نمانید؛ با تست، نقشه را همزمان با حرکت ترسیم کنید تا عدم‌قطعیت کاهش یابد و کیفیت با اطمینان بیشتری ارائه شود.
#تست_نرم‌افزار #کیفیت #بازخورد_سریع #مدیریت_ریسک #Observability #مهندسی_نرم‌افزار #توسعه_چابک #QA
🟣لینک مقاله:
https://cur.at/m1egK0h?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
When Tests Start Drawing the Map
🟢 خلاصه مقاله:
** در دنیای واقعی توسعه، محیط‌های تست به‌ندرت کامل‌اند: اطلاعات ناقص است، وابستگی‌ها تغییر می‌کنند و قطعیت کم است. Charlie Kingston پیشنهاد می‌کند به تست مثل «نقشه‌کش» نگاه کنیم؛ هر تست یک کاوش است که مرزها، خطرها و رفتارهای واقعی سیستم را روشن می‌کند و نقشهای زنده از آنچه می‌دانیم می‌سازد.
با بیان شفاف فرضیه‌ها و تبدیلشان به تست، استفاده از ابزارهـای مشاهده‌پذیری برای رفع نقاط کور، ایجاد چرخه‌های بازخورد سریع و اولویت‌بندی ریسک (مسیرهای بحرانی، حالت‌های خرابی، و درزهای یکپارچه‌سازی)، این نقشه قابل اعتماد می‌شود. تست‌ها فقط دروازه انتشار نیستند؛ دانسته‌های تیم را مستند می‌کنند، قراردادهای بین سرویس‌ها را شفاف می‌سازند و بازطراحی امن را ممکن می‌کنند. با هر تغییر، تست‌ها نشان می‌دهند کجا نقشه با واقعیت نمی‌خواند و باید دقیق‌تر بررسی شود.
ترکیبی از روش‌ها این نقشه را کامل‌تر می‌کند: Contract Testها برای انتظارات بین سرویس‌ها، Property-based Testing برای پوشش لبه‌ها، تست اکتشافی برای کشف ناشناخته‌ها، و پایش مصنوعی در محیط اجرا برای تشخیص تغییر رفتار. پیام نهایی: منتظر مشخصات کامل نمانید؛ با تست، نقشه را همزمان با حرکت ترسیم کنید تا عدم‌قطعیت کاهش یابد و کیفیت با اطمینان بیشتری ارائه شود.
#تست_نرم‌افزار #کیفیت #بازخورد_سریع #مدیریت_ریسک #Observability #مهندسی_نرم‌افزار #توسعه_چابک #QA
🟣لینک مقاله:
https://cur.at/m1egK0h?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
When Tests Start Drawing the Map
How tests that explore become documentation you can trust
❤1
🔵 عنوان مقاله
Apple alerts exploit developer that his iPhone was targeted with government spyware (4 minute read)
🟢 خلاصه مقاله:
اپل به یک توسعه‌دهنده اکسپلویت iOS با نام مستعار Jay Gibson اطلاع داده که آیفون شخصی او در ماه مارس هدف جاسوس‌افزار «مزدور» قرار گرفته است؛ اتفاقی که می‌تواند نخستین مورد مستند از هدف قرار گرفتن توسعه‌دهندگان چنین ابزارهایی توسط همان طبقه از ابزارها باشد. این فرد چند هفته قبل از دریافت هشدار، از شرکت Trenchant (زیرمجموعه L3Harris) اخراج شده بود؛ به اتهام افشای زیرو-دی‌های Chrome، اتهامی که او و همکاران سابقش رد می‌کنند. اپل معمولاً جزئیات فنی یا نسبت‌دهی ارائه نمی‌دهد، اما این هشدارها نشانه خطر جدی تلقی می‌شود. این پرونده نشان میدهد استفاده از جاسوس‌افزارهای تجاری به حوزه متخصصان فنی نیز سرایت کرده و پرسش‌هایی درباره منبع حمله، انگیزه‌ها و راهکارهای حفاظتی مطرح می‌کند.
#Apple #iOS #iPhone #Spyware #MercenarySpyware #L3Harris #Trenchant #Cybersecurity
🟣لینک مقاله:
https://techcrunch.com/2025/10/21/apple-alerts-exploit-developer-that-his-iphone-was-targeted-with-government-spyware/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Apple alerts exploit developer that his iPhone was targeted with government spyware (4 minute read)
🟢 خلاصه مقاله:
اپل به یک توسعه‌دهنده اکسپلویت iOS با نام مستعار Jay Gibson اطلاع داده که آیفون شخصی او در ماه مارس هدف جاسوس‌افزار «مزدور» قرار گرفته است؛ اتفاقی که می‌تواند نخستین مورد مستند از هدف قرار گرفتن توسعه‌دهندگان چنین ابزارهایی توسط همان طبقه از ابزارها باشد. این فرد چند هفته قبل از دریافت هشدار، از شرکت Trenchant (زیرمجموعه L3Harris) اخراج شده بود؛ به اتهام افشای زیرو-دی‌های Chrome، اتهامی که او و همکاران سابقش رد می‌کنند. اپل معمولاً جزئیات فنی یا نسبت‌دهی ارائه نمی‌دهد، اما این هشدارها نشانه خطر جدی تلقی می‌شود. این پرونده نشان میدهد استفاده از جاسوس‌افزارهای تجاری به حوزه متخصصان فنی نیز سرایت کرده و پرسش‌هایی درباره منبع حمله، انگیزه‌ها و راهکارهای حفاظتی مطرح می‌کند.
#Apple #iOS #iPhone #Spyware #MercenarySpyware #L3Harris #Trenchant #Cybersecurity
🟣لینک مقاله:
https://techcrunch.com/2025/10/21/apple-alerts-exploit-developer-that-his-iphone-was-targeted-with-government-spyware/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
TechCrunch
Exclusive: Apple alerts exploit developer that his iPhone was targeted with government spyware
A developer at Trenchant, a leading Western spyware and zero-day maker, was suspected of leaking company tools and was fired. Weeks later, Apple notified him that his personal iPhone was targeted with spyware.
🔵 عنوان مقاله
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.