تولید خودکار تست با LLM و SWE-Agent -عنوان: Automated Test Evolution using LLMs on SWE-bench Verified

---

شرح پروژه

📌 معرفی کلی پروژه
در این پروژه پایان نامه، هدف ما خودکارسازی فرآیند تکامل و ویرایش تست‌ها (Test Evolution) با استفاده از LLM و SWE-Agent است.

ما روی یکی از معتبرترین دیتاست‌های حوزه AI for Software Engineering کار می‌کنیم:

🔗 SWE-bench Verified Dataset
https://github.com/swe-bench/swe-bench

 
🎯 هدف اصلی SWE-bench Verified چه بوده است؟
هدف اصلی دیتاست SWE-bench (و نسخه Verified آن) این بوده است که:

🔹 مدل‌های زبانی یا Agentها بتوانند با ویرایش کد (Program Repair)، تست‌های موجود را pass کنند.
به‌صورت دقیق‌تر:

ورودی:

کد قدیمی (C_old)
تست‌های موجود (T_old)
یک failing test
خروجی مورد انتظار:

تولید یک patch کد که باعث شود تست‌ها pass شوند
در SWE-bench Verified این فرآیند به‌صورت deterministic، پایدار و قابل تکرار طراحی شده تا ارزیابی مدل‌ها منصفانه باشد.

 
🔄 ما چگونه این هدف را تغییر می‌دهیم؟
در این پروژه، جهت مسئله را معکوس می‌کنیم:

❌ ما کد را تغییر نمی‌دهیم
✅ ما تست‌ها را تکامل می‌دهیم
هدف جدید ما:
به‌جای تولید patch برای کد، می‌خواهیم تست‌ها را طوری ویرایش یا گسترش دهیم که با نسخه جدید کد (C_new) سازگار شوند و تغییرات کد را به‌درستی پوشش دهند.

به‌عبارت دیگر، در حالی که SWE-bench کلاسیک بر اصلاح کد تمرکز دارد، پروژه ما تمرکز را به تکامل تست‌ها منتقل می‌کند. در SWE-bench، خروجی اصلی یک patch برای کد است که باعث می‌شود تست‌های موجود pass شوند، اما در پروژه ما خروجی نهایی یک patch برای تست‌ها است که آن‌ها را با نسخه جدید کد سازگار می‌کند. به همین ترتیب، اگر SWE-bench بر رویکرد Test-driven repair متکی است، پروژه ما رویکرد Code-driven test evolution را دنبال می‌کند.

 
📦 دیتاست SWE-bench Verified چیست؟
هر instance در SWE-bench Verified شامل:

یک ریپازیتوری واقعی (مثل astropy، pandas، django، …)
نسخه قدیمی کد (C_old)
نسخه جدید کد بعد از تغییر (C_new)
پچ کد (patch.diff)
تست‌های موجود قبل از تغییر (T_old)
محیط Docker استاندارد برای اجرای دقیق و reproducible

📌 نسخه Verified تضمین می‌کند که:

تست‌ها deterministic هستند
flaky tests حذف شده‌اند
اجرای تست‌ها پایدار و قابل ارزیابی است
 
🎯 هدف نهایی پروژه

تولید خودکار نسخه جدید تست‌ها (T_new) با حداقل تغییر نسبت به T_old، به‌گونه‌ای که:

با C_new سازگار باشد و تمام test ها را pass کند
تغییرات کد را واقعاً تست کند (کاور کند)
و پوشش مناسبی روی بخش‌های تغییر‌یافته ایجاد کند

📌 نکته مهم:
ترجیحا این کار بدون استفاده از issue description، PR text یا gold test patches انجام می‌شود.

 
🔢 ورودی‌ها (Inputs)
Agent فقط باید به موارد زیر دسترسی داشته باشد:

T_old – تست‌های اولیه
C_new – نسخه جدید کد
patch.diff – تفاوت C_old و C_new

سیگنال‌های اجرایی (Runtime Signals):

Failures تست‌ها روی C_new (در صورت وجود)
Coverage فایل‌ها و خطوط تغییر یافته

🚫 مواردی که عمداً استفاده نمی‌کنیم:

Issue description
PR description
Gold test patches
 
🧪 تولید T_new چگونه انجام می‌شود؟
فرآیند تولید T_new به‌صورت مرحله‌ای انجام می‌شود:

1️⃣ ویرایش حداقلی تست‌ها (Minimal Test Edits)
در مرحله اول، Agent تلاش می‌کند با:

اصلاح assertionها
به‌روزرسانی expected behavior
تطبیق تست با API جدید
تست‌ها را pass کند، با حداقل diff نسبت به T_old.

 
2️⃣ بررسی پوشش کد تغییر یافته (Coverage-aware)
پس از pass شدن تست‌ها:

بررسی می‌شود که آیا خطوط و فایل‌های تغییر یافته در patch.diff واقعاً توسط تست‌ها پوشش داده شده‌اند یا نه
 
3️⃣ افزودن تست جدید در صورت نیاز (Additional Tests)
اگر مشخص شود که:

❌ بخش‌هایی از کد تغییر یافته هنوز کاور نشده‌اند
Agent مجاز است:

تست جدید اضافه کند
یا یک تست موجود را گسترش دهد

📌 محدودیت‌ها:

فقط در فایل‌های تست موجود
بدون اضافه کردن helper جدید
بدون اضافه کردن فایل جدید
با حفظ style و ساختار پروژه

هدف این مرحله:

اطمینان از اینکه تغییرات کد واقعاً تست شده‌اند، نه فقط اینکه تست‌ها pass شده باشند.
 
📤 خروجی نهایی (Output)
خروجی سیستم:

✅ T_new
نسخه تکامل‌یافته تست‌ها با ویژگی‌های زیر:

حداقل diff نسبت به T_old
فقط تغییر در فایل‌های تست
سازگار با C_new
پوشش مناسب روی خطوط تغییر یافته
 
🤖 SWE-Agent + LLM
در این پروژه:

SWE-Agent نقش orchestrator را دارد
LLM (مثلاً GPT-4.1 یا مدل‌های مشابه):

تصمیم می‌گیرد چه تستی تغییر کند
کجا assertion اصلاح شود
و چه زمانی تست جدید اضافه شود
📌 سیگنال‌های تصمیم‌گیری Agent:

Failures روی C_new
Coverage gap روی changed files / lines
 
📊 Evaluation نهایی (ارزیابی)
ارزیابی فقط بر اساس pass/fail نیست.

مراحل Evaluation:
1️⃣ Coverage(T_old روی C_old)
2️⃣ Coverage(T_new روی C_new)

معیارهای موفقیت:
T_new حداقل به‌اندازه T_old پوشش داشته باشد
پوشش روی خطوط تغییر یافته افزایش یافته باشد
تست‌ها meaningful باشند (نه overfitting)
📌 این روش، کیفیت واقعی تست‌ها را می‌سنجد، نه صرفاً سبز شدن CI.

 
👥 این پروژه مناسب چه کسانی است؟
اگر به یکی از موارد زیر علاقه‌مند هستید:

Software Testing & CI
AI for Software Engineering
LLM-based Agents
SWE-bench / Agent-based systems
این پروژه کاملاً مناسب شماست.

مهارت ها و تخصص های مورد نیاز

---

---