‏وقتی ایجنت کد می‌نویسه، تست محصول مهم‌تر از تست کده

نویسنده تو پست قبلیش گفته بود اگه یه ایجنت هم کد رو بنویسه و هم تست‌هاش رو، هر دو ممکنه یه سوءبرداشت مشترک داشته باشن و بیلد سبز دیگه یه تأیید مستقل حساب نمی‌شه. حالا تو این مقاله جواب می‌ده که پس باید کجا سرمایه‌گذاری کرد: روی product verification، یعنی بررسی اینکه محصول برای کاربر درست کار می‌کنه، با انتظاراتی که بیرون از چرخهٔ کدنویسی تعریف شدن.

به گفتهٔ نویسنده، هرم تست (همون مدلی که Mike Cohn سال ۲۰۰۹ معرفی کرد: کلی unit test ارزون پایین و چند تا E2E گرون بالا) قانون طبیعت نبود، فقط یه حساب‌وکتاب هزینه بود. حالا سه چیز عوض شده: unit testهای سبز ثابت نمی‌کنن محصول کار می‌کنه، نگهداری تست‌های E2E (مثل آپدیت selectorها و fixtureها) برای ایجنت کار روزمره‌ست، و تو تیم اونا (Swamp) فاصلهٔ پیدا کردن باگ تا رفعش اغلب چند دقیقه‌ست. البته نویسنده می‌گه باگی که به کاربر برسه هنوز می‌تونه داده رو خراب کنه یا اعتماد رو از بین ببره.

خیلیا الان پیشنهاد می‌دن هرم رو برعکس کنیم، یعنی E2E بیشتر و unit test کمتر. نویسنده معتقده این کافی نیست، چون فقط سطح تست عوض می‌شه، نه منبع انتظارات. اگه تست E2E هم از همون برداشت ایجنت بیاد، می‌تونه با اطمینان چیز اشتباهی رو تأیید کنه. edge caseهایی که واقعاً دردسر درست می‌کنن، همونایی‌ان که تو دنیای کاربر هستن و اصلاً تو ذهن ایجنت نبودن.

حرف اصلی مقاله اینه: استقلال یه تست به سطحش ربطی نداره، به این ربط داره که انتظاراتش از کجا میان و کی می‌تونه عوضشون کنه. این انتظارات باید از product definition، تحقیق کاربر یا دانش دامنه بیان، نه از خود ایجنت. باید هم محافظت بشن، چون ایجنتی که بتونه یه تست شکست‌خورده رو ادیت کنه تا سبز شه، کل هدف رو از بین برده. شکلش هم مهم نیست: UAT (تست پذیرش کاربر)، contract test یا چک‌های خودکار روی لایهٔ API.

نویسنده یادآوری می‌کنه این ایدهٔ تازه‌ای نیست. James Whittaker تو Google روشی به اسم ACC (یعنی Attributes، Components، Capabilities) داشت که تست رو روی تقاطع کیفیت‌های محصول، کامپوننت‌های کاربرمحور و قابلیت‌هایی که باید ارائه بدن متمرکز می‌کرد. حالا ایجنت‌ها می‌تونن نگهداری این نگاشت‌ها و مکانیک تست رو انجام بدن، ولی هر تغییری تو assertionها یا قابلیت‌های پوشش‌داده‌شده باید بیرون از چرخهٔ پیاده‌سازی بررسی بشه.

به گفتهٔ نویسنده، تو تیمشون UAT با وجود هزاران unit test سبز، باگ‌های واقعی رو سر مرز ریلیز گرفته. با این حال هرم تست هنوز جایی داره: کدی که درستیش از بیرون تعریف شده، مثل تابع رمزنگاری، موتور قیمت‌گذاری، قانون رگولاتوری یا مدل دسترسی‌ها، هنوز از unit test سود می‌بره. چیزی که دیگه جواب نمی‌ده اینه که تعداد یا coverage تست‌ها رو جایگزین تأیید مستقل محصول کنیم.

نکات کلیدی:

• وقتی یه ایجنت هم کد و هم تست رو می‌نویسه، هر دو می‌تونن یه سوءبرداشت مشترک داشته باشن.
• هرم تست Mike Cohn از ۲۰۰۹ بر پایهٔ هزینه بود و ایجنت‌ها این هزینه‌ها رو عوض کردن.
• برعکس‌کردن هرم کافی نیست چون منبع انتظارات تست عوض نمی‌شه.
• انتظارات باید از product definition، تحقیق کاربر یا دانش دامنه بیان و ایجنت نتونه تغییرشون بده.
• روش ACC گوگل (Attributes، Components، Capabilities) نمونهٔ قدیمی همین تفکر محصول‌محوره.
• unit test برای قوانین بیرونی مثل رمزنگاری، قیمت‌گذاری و مدل دسترسی هنوز ارزشمنده.