‏تست، چشم و گوش ایجنت‌های کدنویس

نویسنده می‌گه مدل‌های امروزی اونقدر خوب کد می‌نویسن که گلوگاه اصلی رفته سمت verification، یعنی اینکه بفهمیم کدی که نوشتن واقعاً درسته. اگه ایجنت نتونه کارشو خودش چک کنه، عملاً داره حدس می‌زنه و آدم باید diff بخونه، اپ رو تست کنه و باگ گزارش بده. این کندترین و گرون‌ترین حلقه‌ست و برای بیشتر از یه نفر جواب نمی‌ده. به گفتهٔ نویسنده، یه حلقهٔ بازخورد خیلی بهتر از یه مدل کمی بهتر ارزش داره.

اولین پیشنهاد E2E test هست (یعنی تستی که کار یه کاربر واقعی رو از اول تا آخر شبیه‌سازی می‌کنه، مثل ثبت‌نام و خرید). این تست‌ها رو سخت می‌شه دور زد: یا کل ماجرا کار می‌کنه یا نه. در حالی که یه unit test با mock ممکنه پاس بشه چون ایجنت و تست یه برداشت غلط مشترک دارن. E2E همچنین «تموم شد» رو تعریف می‌کنه: «این تست رو پاس کن» هدفیه که ایجنت خودش دنبالش می‌ره. البته کندتر و ناپایدارترن، پس بهتره چندتا تست کم ولی مهم داشت.

دومی property-based testing هست، یعنی به جای مثال، یه قانون می‌نویسی که همیشه باید برقرار باشه و ابزار هزاران ورودی می‌سازه تا بشکنتش. ابزارهایی مثل fast-check برای JS/TS، Hypothesis برای Python و proptest برای Rust این کارو می‌کنن و ورودی خراب رو تا کوچیک‌ترین حالت ممکن کوچیک می‌کنن. نمونه‌هاش: encode و بعد decode همون مقدار اول رو بده، موجودی هیچ‌وقت منفی نشه، دوبار اجرا کردن یه migration همون اثر یه بار رو داشته باشه. نکته اینه که ایجنت دیگه نمی‌تونه فقط مثال‌هایی بسازه که با منطق خودش جور درمیان.

سومی differential testing هست، به‌خصوص برای بازنویسی و migration: سیستم قدیمی و جدید رو با ورودی‌های یکسان کنار هم اجرا می‌کنی و سیستم قدیمی می‌شه مرجع درستی. ورودی‌ها رو تصادفی بساز یا بخشی از ترافیک واقعی رو replay کن. نویسنده توصیه می‌کنه تفاوت‌های بی‌اهمیت مثل ترتیب رو قبل از مقایسه نرمال کنی و تغییرات عمدی رو با دلیل تو یه لیست ثبت کنی.

نویسنده تأکید می‌کنه تست‌ها باید سریع و deterministic باشن (یعنی هر بار همون نتیجه رو بدن). اگه تست flaky باشه، ایجنت یاد می‌گیره به جای درست کردن مشکل، فقط دوباره اجرا کنه. اگه ۱۵ دقیقه طول بکشه، کمتر اجرا می‌کنه و نمی‌فهمه کدوم تغییر خرابی آورده. راه‌حل: seeded randomness، ساعت ثابت، شبکهٔ کنترل‌شده، خروجی کوتاه و جدا کردن فوری تست‌های flaky. حرف آخرش اینه که قبل از کد، معیار موفقیت رو بنویس؛ کار آدم دیگه خوندن تک‌تک خط‌ها نیست، تعریف کردن موفقیته.

نکات کلیدی:

• گلوگاه کار با ایجنت‌ها از نوشتن کد رفته سمت چک کردن درستیش
• E2E test مرجع اصلیه و دور زدنش برای ایجنت سخته
• property test با ابزارهایی مثل fast-check، Hypothesis و proptest هزاران ورودی برای شکستن قانون می‌سازه
• تو migration، سیستم قدیمی با differential testing مرجع درستی می‌شه
• تست کند یا flaky به ایجنت یاد می‌ده retry کنه به جای اینکه مشکل رو حل کنه