آینده تست‌نویسی در .NET؛ وقتی هوش مصنوعی خودش را قضاوت می‌کند!

اگر در اکوسیستم دات‌نت فعالیت می‌کنید، حتماً می‌دانید که ورود AI به اپلیکیشن‌ها، مدل‌های سنتی تست‌نویسی را به چالش کشیده است. دیگر صرفاً چک کردن یک خروجی ثابت کافی نیست؛ ما با مدل‌های زبانی (LLM) سر و کار داریم که پاسخ‌هایشان متغیر است.
مایکروسافت با معرفی کتابخانه‌های Microsoft.Extensions.AI.Evaluation و ابزارهای جدید در Visual Studio 2026، پازل تست‌نویسی هوشمند را کامل کرده است.

💡 نکات کلیدی ویدیو (AI-Powered Testing in VS):

در ویدیوی جدید کانال دات‌نت، مک‌کنا بارلو (PM تیم ابزارهای دات‌نت) نکات بسیار مهمی را مطرح کرد:
1️⃣ تست‌نویسی خودکار با Copilot: حالا GitHub Copilot می‌تواند برای کل Solution شما به‌صورت یکجا Unit Testهای باکیفیت بنویسد. این یعنی دیگر لازم نیست ساعت‌ها وقت صرف نوشتن کدهای تکراری تست کنید.

2️⃣ ترکیب Code Coverage و AI: ابزار Code Coverage در ویژوال استودیو حالا هوشمندتر شده؛ نقاطی از کد که تست نشده‌اند را شناسایی کرده و مستقیماً به Copilot پیشنهاد می‌دهد تا برای همان بخش‌های پرریسک، تست تولید کند.

3️⃣ گزارش‌های بصری (AI Eval Reporting): با ابزار جدید dotnet aieval می‌توانید گزارش‌های گرافیکی دقیقی در مرورگر ببینید که نشان می‌دهد مدل هوش مصنوعی شما در چه بخش‌هایی (مثلاً در Groundedness یا صحت اطلاعات) ضعف داشته است.

4️⃣ فراتر از Black Box: هدف این ابزارها این است که خروجی AI دیگر یک "جعبه سیاه" نباشد. شما می‌توانید دقیقاً بفهمید چرا یک مدل امتیاز پایینی گرفته و با چه منطقی پاسخ داده است.

🛠 کتابخانه Microsoft.Extensions.AI.Evaluation شامل چیست؟
این پکیج‌ها فرآیند ارزیابی را به چهار لایه تقسیم می‌کنند:
✅ ارزیابی کیفی (Quality): سنجش میزان مرتبط بودن (Relevance) و انسجام (Coherence) پاسخ‌ها.

✅ ارزیابی ایمنی (Safety): شناسایی خودکار محتوای سمی، نفرت‌پراکنی یا کد‌های مخرب تولید شده توسط AI.

✅ ارزیابی مستند بودن (Groundedness): حیاتی‌ترین بخش برای جلوگیری از توهم (Hallucination)؛ چک می‌کند که آیا AI بر اساس دیتای واقعی شما حرف می‌زند یا از خودش داستان می‌سازد!

✅ ارزیابی کلاسیک (NLP): استفاده از معیارهای BLEU و F1 برای سنجش شباهت متنی با پاسخ‌های مرجع.

چرا این موضوع مهم است؟
در دنیای واقعی، ما نمی‌توانیم به خروجی مدل‌های هوش مصنوعی اعتماد صددرصدی داشته باشیم. این کتابخانه‌ها به ما "اعتماد سیستماتیک" می‌دهند. یعنی قبل از اینکه کاربر نهایی با یک پاسخ اشتباه روبرو شود، سیستم تست شما آن را شکار می‌کند.

📌 ویژگی طلایی: تمام این فرآیندها دارای سیستم Caching هستند؛ یعنی اگر یک تست را دوباره اجرا کنید و ورودی تغییری نکرده باشد، هزینه‌ای برای API پرداخت نمی‌کنید و نتیجه بلافاصله نمایش داده می‌شود.

📺 مشاهده ویدیو کامل در یوتیوب:
🔗 https://youtu.be/Bkn78klGhtc?si=c5dBLw1y7ituLTFH
📖 مطالعه مستندات رسمی:
🔗 https://learn.microsoft.com/en-us/dotnet/ai/evaluation/libraries

#dotnet #csharp #VisualStudio2026 #AI #Testing #GitHubCopilot #Programming #SoftwareEngineering #هوش_مصنوعی #برنامه_نویسی

🎺برای یادگیری بیشتر و دریافت مطالب مفید در زمینه .NET و برنامه‌نویسی، به کانال ما بپیوندید!

📚💻 @dotnetcode 🖥👨‍💻

🚨 تغییر مهم در MassTransit: لایسنس تجاری از نسخه ۹.۰.۰

اگر در پروژه‌های دات‌نتی از کتابخانه MassTransit استفاده می‌کنید، مراقب آپدیت‌های جدید باشید. از نسخه 9.0.0 به بعد، این کتابخانه مدل لایسنس خود را به Commercial تغییر داده است.

خلاصه وضعیت جدید:
🔹 نسخه‌های ۸ و قدیمی‌تر: همچنان رایگان و Open Source (Apache 2.0) باقی می‌مانند.
🔹 نسخه ۹ و بالاتر: برای شرکت‌هایی با درآمد بالای ۱ میلیون دلار در سال پولی است.
🔹 استارتاپ‌ها و توسعه‌دهندگان مستقل: اگر درآمد سالانه زیر ۱ میلیون دلار باشد، همچنان می‌توانید با تخفیف ۱۰۰ درصدی (رایگان) استفاده کنید.

---

🛠 راهکار فنی: جلوگیری از آپدیت خودکار به نسخه پولی

برای اینکه ابزارهایی مثل NuGet یا Dependabot به صورت خودکار پروژه شما را به نسخه ۹ (پولی) ارتقا ندهند، باید ورژن را در فایل .csproj قفل کنید. استفاده از براکت `[]` به معنای اجبار روی یک نسخه دقیق است:

<PackageReference Include="MassTransit" Version="[8.5.7]" />

چرا این کار مهم است؟

* نوشتن Version="8.5.7" به NuGet اجازه می‌دهد نسخه‌های بالاتر (مثل 9.0.1) را هم نصب کند.
* اما Version="[8.5.7]" یعنی فقط و فقط همین نسخه نصب شود و جلوی ارتقای ناخواسته به نسخه پولی را می‌گیرد.

اگر پروژه‌ی بزرگی دارید که فعلاً بودجه خرید لایسنس ندارد، حتماً این تغییر را در پکیج‌های خود اعمال کنید.

🎺برای یادگیری بیشتر و دریافت مطالب مفید در زمینه .NET و برنامه‌نویسی، به کانال ما بپیوندید!

📚💻 @dotnetcode 🖥👨‍💻

#DotNet #MassTransit #CSharp #Programming_Tips #Microservices

🔥 نکته حیاتی در Hangfire: جنگ با ساعت و تایم‌زون‌ها! ⏰🌍

اگر تا حالا براتون پیش اومده که جابی رو برای ساعت ۸ صبح تنظیم کردید ولی ساعت ۱۱:۳۰ اجرا شده، این پست برای شماست!

⚠️ ماجرا چیه؟
هنگ‌فایر (Hangfire) به صورت پیش‌فرض (Default) همه جاب‌های تکرارشونده (Recurring Jobs) رو بر مبنای ساعت UTC اجرا می‌کنه. یعنی اگر تنظیمات تایم‌زون رو بهش ندید، باید اختلاف ساعت ایران با گرینویچ رو دستی حساب کنید که اصلا جالب نیست.

حالا اگر بخوایم بگیم "به وقت ایران اجرا شو"، با یه چالش جدید روبرو می‌شیم:

🔸 ویندوز می‌گه: "Iran Standard Time"

🔸 لینوکس/داکر می‌گه: "Asia/Tehran"
اگر این تفاوت هندل نشه، روی سرور لینوکسی یا کانتینر داکر به خطای TimeZoneNotFoundException می‌خورید! 🤯

✅ راه حل نهایی (Cross-Platform):
با این تیکه کد، هم مشکل UTC رو حل کنید و هم کدی بنویسید که روی ویندوز، لینوکس و مک بدون تغییر کار کنه:

using System.Runtime.InteropServices;

// 1. تشخیص خودکار شناسه تایم‌زون بر اساس سیستم‌عامل
// Windows -> "Iran Standard Time"
// Linux/Docker -> "Asia/Tehran"
var tehranId = RuntimeInformation.IsOSPlatform(OSPlatform.Windows)
  ? "Iran Standard Time"
  : "Asia/Tehran";

// 2. تنظیم ساعت به وقت ایران
RecurringJob.AddOrUpdate(
    type.FullName, 
    () => job.ExecuteAsync(), 
    attribute.CronExpression, 
    new RecurringJobOptions
    {
        // خداحافظ UTC، سلام تهران! 👋
        TimeZone = TimeZoneInfo.FindSystemTimeZoneById(tehranId)
    }
);

💡 با این روش، دیگه نگران جلو/عقب کشیدن ساعت‌ها یا تفاوت محیط لوکال و سرور نباشید.

🔗 بحث مرتبط در کامیونیتی هنگ‌فایر:
https://discuss.hangfire.io/t/need-local-time-instead-of-utc/279/7


🎺برای یادگیری بیشتر و دریافت مطالب مفید در زمینه .NET و برنامه‌نویسی، به کانال ما بپیوندید!

📚💻 @dotnetcode 🖥

#CSharp #DotNet #Hangfire #Docker #Backend #TimeZone #Tips