تست‌نویسی و دیباگ با هوش مصنوعی؛ از خطا تا تست رگرسیون

برای دیباگ با هوش مصنوعی، خطا را قابل بازتولید کن، علت را در کد پیدا کن و اصلاح را با تست بررسی کن. مدل می‌تواند فرضیه و تغییر پیشنهاد بدهد، اما توضیح قانع‌کننده به‌تنهایی نشان نمی‌دهد مشکل حل شده است. در این راهنما، یک خطای فرم را تا تست رگرسیون دنبال می‌کنیم و برای هر مرحله پرامپت قابل استفاده می‌دهیم.

قبل از درخواست اصلاح، چه اطلاعاتی آماده کنیم؟

این پنج مورد معمولاً از چسباندن کل مخزن مفیدترند:

1. رفتار فعلی: چه اتفاقی می‌افتد و با چه مراحلی؟
2. رفتار مورد انتظار: نتیجهٔ درست چیست؟
3. شواهد: متن خطا، پاسخ درخواست یا لاگ مرتبط.
4. محدوده: فایل یا مؤلفهٔ مربوط و آخرین تغییر مرتبط.
5. محیط: نسخهٔ زبان یا چارچوب، سیستم‌عامل و فرمان اجرای تست.

کلید API، توکن، رمز و اطلاعات مشتری را از نمونهٔ لاگ حذف کن. اگر مسئله فقط در یک محیط دیده می‌شود، تفاوت تنظیمات و مراحل اجرا را هم بنویس.

مثال: دوبار کلیک، دو درخواست

فرض کن کاربر روی دکمهٔ ثبت سفارش دوبار کلیک می‌کند و فرم دو درخواست می‌فرستد. درخواست اولیه را این‌طور بنویس:

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

ممکن است علت، ثبت دوبارهٔ رویداد یا آزادشدن زودهنگام وضعیت ارسال باشد. از مدل بخواه هر فرضیه را به فایل و مسیر اجرای مشخص وصل کند. جملهٔ «یک debounce اضافه کن» بدون بررسی رفتار، هنوز تشخیص علت نیست.

ابتدا تستی بنویس که خطای اصلی را نشان دهد

تست رگرسیون باید پیش از اصلاح شکست بخورد. اگر از ابتدا پاس می‌شود، احتمالاً رفتار مشکل‌دار را پوشش نمی‌دهد.

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

در این مثال، بهتر است تست خودِ رفتار را بسنجد: تعداد درخواست‌ها و امکان تلاش دوباره. تستی که فقط نام متغیر isSubmitting را در فایل جست‌وجو می‌کند، چنین چیزی را ثابت نمی‌کند.

اصلاح محدود، با پوشش مسیر خطا

بعد از تأیید تشخیص و تست، تغییر را بخواه:

علت ارسال دوباره را با کمترین تغییر لازم رفع کن. مسیر موفقیت و خطا باید وضعیت ارسال را آزاد کنند. ظاهر فرم، قرارداد API و تغییرات قبلی من را نگه دار. سپس همان تست و تست‌های مرتبط را اجرا کن.

این چهار حالت را بررسی کن:

برای جلوگیری از ثبت سفارش تکراری در کل سامانه، ممکن است سازوکار سمت سرور هم لازم باشد. تست دکمه چنین تضمینی نمی‌دهد؛ بررسی آن را با قرارداد API و رفتار واقعی سرور ادامه بده.

وقتی متن خطا مشخص است

برای خطایی مثل Cannot read properties of undefined فقط خاموش‌کردن استثنا را نخواه. مدل باید منشأ داده و حالت‌های ممکن را بررسی کند:

این خطا در ProductList دیده می‌شود. بررسی کن داده قبل از رسیدن به مؤلفه چه شکل‌هایی دارد. حالت بارگذاری، فهرست خالی و شکست دریافت داده را از هم جدا کن. اگر optional chaining پیشنهاد می‌دهی، توضیح بده کاربر در هر حالت چه چیزی می‌بیند.

ممکن است ?.map از توقف صفحه جلوگیری کند، اما خطای دریافت داده را پنهان کند. معیار درست، رفتار صفحه برای کاربر است. برای بررسی تغییرات پیش از ادغام، راهنمای بازبینی کد با هوش مصنوعی را ببین.

تست واحد، تست یکپارچه و بررسی مرورگر چه تفاوتی دارند؟

تست واحد یک بخش محدود را بررسی می‌کند. تست یکپارچه ارتباط چند بخش را می‌سنجد. بررسی مرورگر نشان می‌دهد مسیر قابل مشاهده برای کاربر چه رفتاری دارد. برای یک خطای رابط، ممکن است هر سه لازم باشند.

در پایان از دستیار گزارش مشخص بخواه:

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

اگر پایگاه داده یا سرویس لازم در دسترس نیست، آن را شکست یا موفقیت برنامه حساب نکن. آن بخش هنوز بررسی نشده است.

اجرای این روش با آیرا کد

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

cd path/to/project
aira

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

چه زمانی اطلاعات بیشتری لازم است؟

خطاهای هم‌زمانی، تفاوت شبکه، تنظیمات محیط و مشکلاتی که فقط زیر بار رخ می‌دهند، ممکن است با یک نمونهٔ کد تشخیص داده نشوند. از مدل بخواه مشاهده‌ای پیشنهاد بدهد که بین فرضیه‌ها فرق بگذارد: زمان درخواست‌ها، ترتیب رویدادها یا مقدار یک تنظیم مشخص. با همان شاهد ادامه بده، نه با بازنویسی تصادفی بخش‌های بیشتر.

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