🔵 عنوان مقاله
Finally: Unit Testing for LLMs That Doesn't Require a PhD or $100K Budget
🟢 خلاصه مقاله:
** دکتر Ernesto Lee نشان میدهد برای ساخت اپلیکیشنهای مبتنی بر LLM لازم نیست PhD یا بودجههای بسیار بزرگ داشته باشید تا تست خودکار جدی و مؤثر پیاده کنید. ایده اصلی این است که هر prompt، chain و فراخوانی ابزار را مثل یک واحد مستقل با مشخصات روشن ببینید و برای آنها تست بنویسید: از اعتبارسنجی ساختار خروجی (مثلاً JSON Schema) و الزامات فیلدها، تا چکهای ایمنی/سیاست و نمونههای طلایی دامنهای. با snapshot test، دادههای نمونه کمحجم اما پوششدهنده لبهها، و mock/stub برای وابستگیهای خارجی، تستها سریع، ارزان و قابل تکرار میمانند.
برای کنترل هزینه و نوسان، میتوان پاسخها را cache کرد، بیشتر تستها را با temperature=0 اجرا نمود، محدودیت توکن گذاشت، و مجموعه تستهای «سریع» را از ارزیابیهای «سنگینتر» دورهای جدا کرد. نسخهدهی به promptها و دادههای طلایی، گزارشکردن معیارها و اتصال این چرخه به CI باعث میشود هر تغییر کد یا prompt فوراً ارزیابی شود و رگرسیونها دیده شوند. در صورت شکست تست، سریع مشخص کنید مشکل از تغییر prompt است، drift مدل بالادستی یا وابستگی ابزار، و همان یادگیری را به تستها برگردانید.
نتیجه این رویکرد، چرخه توسعه سریعتر با اطمینان بیشتر و هزینه کنترلشده است. پیام Lee روشن است: Unit Testing عملی و مقیاسپذیر برای LLMها در دسترس همه تیمهاست، نه فقط تیمهای بزرگ.
#LLM
#UnitTesting
#AIEngineering
#TestingAutomation
#MLOps
#PromptEngineering
#ContinuousIntegration
#QualityAssurance
🟣لینک مقاله:
https://cur.at/YHqFc9m?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Finally: Unit Testing for LLMs That Doesn't Require a PhD or $100K Budget
🟢 خلاصه مقاله:
** دکتر Ernesto Lee نشان میدهد برای ساخت اپلیکیشنهای مبتنی بر LLM لازم نیست PhD یا بودجههای بسیار بزرگ داشته باشید تا تست خودکار جدی و مؤثر پیاده کنید. ایده اصلی این است که هر prompt، chain و فراخوانی ابزار را مثل یک واحد مستقل با مشخصات روشن ببینید و برای آنها تست بنویسید: از اعتبارسنجی ساختار خروجی (مثلاً JSON Schema) و الزامات فیلدها، تا چکهای ایمنی/سیاست و نمونههای طلایی دامنهای. با snapshot test، دادههای نمونه کمحجم اما پوششدهنده لبهها، و mock/stub برای وابستگیهای خارجی، تستها سریع، ارزان و قابل تکرار میمانند.
برای کنترل هزینه و نوسان، میتوان پاسخها را cache کرد، بیشتر تستها را با temperature=0 اجرا نمود، محدودیت توکن گذاشت، و مجموعه تستهای «سریع» را از ارزیابیهای «سنگینتر» دورهای جدا کرد. نسخهدهی به promptها و دادههای طلایی، گزارشکردن معیارها و اتصال این چرخه به CI باعث میشود هر تغییر کد یا prompt فوراً ارزیابی شود و رگرسیونها دیده شوند. در صورت شکست تست، سریع مشخص کنید مشکل از تغییر prompt است، drift مدل بالادستی یا وابستگی ابزار، و همان یادگیری را به تستها برگردانید.
نتیجه این رویکرد، چرخه توسعه سریعتر با اطمینان بیشتر و هزینه کنترلشده است. پیام Lee روشن است: Unit Testing عملی و مقیاسپذیر برای LLMها در دسترس همه تیمهاست، نه فقط تیمهای بزرگ.
#LLM
#UnitTesting
#AIEngineering
#TestingAutomation
#MLOps
#PromptEngineering
#ContinuousIntegration
#QualityAssurance
🟣لینک مقاله:
https://cur.at/YHqFc9m?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Finally: Unit Testing for LLMs That Doesn’t Require a PhD or $100K Budget
Stop manually reviewing AI outputs like it’s 2019. This pytest-style framework (DeepEval) tests LLMs with 40+ metrics, catches…
❤2
🔵 عنوان مقاله
How We Utilize AI Agents in Our Testing and Quality Processes
🟢 خلاصه مقاله:
این مقاله با روایت Utku Kılınçcı چهار کاربرد عملی از بهکارگیری AI agents در تست و تضمین کیفیت را توضیح میدهد: ۱) تبدیل نیازمندیها به تستهای قابل اجرا و بهروزرسانی مداوم سبد تست با تغییرات مشخصات، ۲) نقش همکار اکتشافی برای کشف سناریوهای مرزی، ثبت شواهد و بازتولید مشکل، ۳) تحلیل و اولویتبندی باگها از طریق خلاصهسازی لاگها، خوشهبندی خطاها و ارائه سرنخهای ریشهیابی، و ۴) بهبود پایداری رگرسیون و درگاههای کیفی CI با شناسایی تستهای flaky، پیشنهاد خوددرمانی و بهینهسازی پایپلاین. در همه موارد، نظارت انسانی، رعایت حریم داده و سنجش نتایج (پوشش، MTTR، روند flakiness و زمان چرخه) ضروری است. نتیجه: پذیرش تدریجی AI agents روی مسائل واقعی، سرعت، پایداری و پوشش تست را بهطور ملموس افزایش میدهد بیآنکه مالکیت کیفیت را تضعیف کند.
#SoftwareTesting #AIagents #QualityAssurance #TestAutomation #BugTriage #ContinuousIntegration #SoftwareQuality #DevOps
🟣لینک مقاله:
https://cur.at/qRpZzn9?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How We Utilize AI Agents in Our Testing and Quality Processes
🟢 خلاصه مقاله:
این مقاله با روایت Utku Kılınçcı چهار کاربرد عملی از بهکارگیری AI agents در تست و تضمین کیفیت را توضیح میدهد: ۱) تبدیل نیازمندیها به تستهای قابل اجرا و بهروزرسانی مداوم سبد تست با تغییرات مشخصات، ۲) نقش همکار اکتشافی برای کشف سناریوهای مرزی، ثبت شواهد و بازتولید مشکل، ۳) تحلیل و اولویتبندی باگها از طریق خلاصهسازی لاگها، خوشهبندی خطاها و ارائه سرنخهای ریشهیابی، و ۴) بهبود پایداری رگرسیون و درگاههای کیفی CI با شناسایی تستهای flaky، پیشنهاد خوددرمانی و بهینهسازی پایپلاین. در همه موارد، نظارت انسانی، رعایت حریم داده و سنجش نتایج (پوشش، MTTR، روند flakiness و زمان چرخه) ضروری است. نتیجه: پذیرش تدریجی AI agents روی مسائل واقعی، سرعت، پایداری و پوشش تست را بهطور ملموس افزایش میدهد بیآنکه مالکیت کیفیت را تضعیف کند.
#SoftwareTesting #AIagents #QualityAssurance #TestAutomation #BugTriage #ContinuousIntegration #SoftwareQuality #DevOps
🟣لینک مقاله:
https://cur.at/qRpZzn9?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
How We Utilize AI Agents in Our Testing and Quality Processes
Hello everyone. In this article, We will try to explain how we utilize AI tools in our team at Trendyol. The purpose of this article is to…
🔵 عنوان مقاله
It's Not Your Tests, It's Your Testability
🟢 خلاصه مقاله:
**
بیثباتی تستها همیشه تقصیر تستها نیست؛ اغلب ریشه در سیستم کمتستپذیر دارد. وقتی زمان، همروندی، تصادفیبودن یا وابستگیهای بیرونی کنترلنشده باشند، تستها ناپایدار میشوند. راهحل، ارتقای تستپذیری است: قابلکنترل و قابلمشاهده کردن سیستم، تزریق زمان و بذر تصادفی، جداسازی مرزهای شبکه با قراردادها و فیکها، و هرمتیککردن محیط تست. Gil Zilberfeld توصیه میکند برای جلب حمایت، هزینه فلیکینس را با داده نشان دهید و از بردهای کوچک (مثل افزودن seam، تزریق وابستگی برای زمان/I-O، و تستهای قراردادی) شروع کنید. با گنجاندن تستپذیری در تصمیمهای معماری و معیارهای پذیرش، تیم از آتشنشانی تستهای flaky به ساخت نرمافزار ذاتاً تستپذیر و قابلاتکا منتقل میشود.
#Testability #FlakyTests #SoftwareTesting #QualityEngineering #DevOps #ContinuousIntegration #TestDesign #Observability
🟣لینک مقاله:
https://cur.at/3RbJDxt?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
It's Not Your Tests, It's Your Testability
🟢 خلاصه مقاله:
**
بیثباتی تستها همیشه تقصیر تستها نیست؛ اغلب ریشه در سیستم کمتستپذیر دارد. وقتی زمان، همروندی، تصادفیبودن یا وابستگیهای بیرونی کنترلنشده باشند، تستها ناپایدار میشوند. راهحل، ارتقای تستپذیری است: قابلکنترل و قابلمشاهده کردن سیستم، تزریق زمان و بذر تصادفی، جداسازی مرزهای شبکه با قراردادها و فیکها، و هرمتیککردن محیط تست. Gil Zilberfeld توصیه میکند برای جلب حمایت، هزینه فلیکینس را با داده نشان دهید و از بردهای کوچک (مثل افزودن seam، تزریق وابستگی برای زمان/I-O، و تستهای قراردادی) شروع کنید. با گنجاندن تستپذیری در تصمیمهای معماری و معیارهای پذیرش، تیم از آتشنشانی تستهای flaky به ساخت نرمافزار ذاتاً تستپذیر و قابلاتکا منتقل میشود.
#Testability #FlakyTests #SoftwareTesting #QualityEngineering #DevOps #ContinuousIntegration #TestDesign #Observability
🟣لینک مقاله:
https://cur.at/3RbJDxt?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
TestinGil | By Gil Zilberfeld
It’s Not Your Tests, It’s Your Testability | TestinGil
Let's talk about that test. The one that's always flaky. The one that takes twenty minutes to run and fails for a different reason every time. Your first instinct is to blame the test. Maybe the locator is wrong, maybe the wait time isn't long enough. But…
🔵 عنوان مقاله
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…