تست قرارداد API با کمک هوش مصنوعی؛ از انتظار کلاینت تا تأیید سرویس

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

قرارداد دقیقاً چه چیزی را پوشش می‌دهد؟

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

در گردش‌کار Pact، انتظار مصرف‌کننده به یک قرارداد تبدیل می‌شود و ارائه‌دهنده آن را جداگانه تأیید می‌کند. این دو سوی بررسی را با یک mock ثابت که هرگز با سرویس مقایسه نمی‌شود اشتباه نگیرید.

مثال: جزئیات یک سفارش

فرض آموزشی: کلاینت فعلی برای GET /orders/42 به پاسخ زیر وابسته است:

{"id":"42","status":"pending"}

کلاینت در این مثال فقط pending و shipped را می‌شناسد و برای سفارش ناموجود، 404 را طبق قرارداد خود مدیریت می‌کند. این مقادیر قانون عمومی همهٔ APIها نیستند؛ باید با قرارداد واقعی پروژه جایگزین شوند.

افزودن فیلد همیشه بی‌خطر نیست؛ parser سخت‌گیر یا امضای پاسخ می‌تواند حساس باشد. همچنین تأیید صرف نوع رشته، فهرست مقادیر مجاز status را پوشش نمی‌دهد.

نقش مناسب دستیار در چهار مرحله

1. کد مصرف‌کننده و نمونهٔ پاسخ را بخواند و وابستگی‌های واقعی را با مسیر فایل مشخص کند.
2. موارد موجود، ناموجود، فیلد حذف‌شده و نوع نادرست را پیشنهاد کند؛ رفتار حدسی را جدا علامت بزند.
3. تست مصرف‌کننده و حالت‌های دادهٔ ارائه‌دهنده را با چارچوب موجود پروژه آماده کند.
4. فرمان اجرا و نتیجه را گزارش کند؛ بازبین انسانی تطبیق قرارداد با نیاز محصول را بررسی کند.

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

یک تمرین محلی، با مرز روشن

کد زیر فقط حساسیت یک assertion به نوع داده و مقدار وضعیت را نشان می‌دهد. آن را در یک فایل .mjs با Node.js اجرا کنید؛ به شبکه وصل نمی‌شود و جای تست قرارداد کامل را نمی‌گیرد.

import assert from 'node:assert/strict';
function checkOrder(body) {
  assert.equal(typeof body.id, 'string');
  assert.ok(['pending', 'shipped'].includes(body.status));
}
checkOrder({ id: '42', status: 'pending' });
assert.throws(() => checkOrder({ id: 42, status: 'pending' }));
assert.throws(() => checkOrder({ id: '42', status: 'queued' }));

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

gate انتشار را به نسخه‌ها متصل کنید

نسخه یا commit مصرف‌کننده، قرارداد تولیدشده و نسخهٔ ارائه‌دهنده‌ای را که آن را تأیید کرده ثبت کنید. نتیجهٔ سبز برای نسخهٔ دیروز، اثبات نسخهٔ امروز نیست. برای تغییر ناسازگار، یا سازگاری عقب‌رو حفظ شود یا ارتقای مصرف‌کننده و ارائه‌دهنده طبق برنامهٔ روشن انجام شود.

یک تغییر کنترل‌شده مانند تبدیل id به عدد در شاخهٔ آزمایشی وارد کنید. اگر بررسی همچنان سبز است، ممکن است تست مسیر درست را اجرا نکرده، قرارداد قدیمی استفاده شده یا assertion بیش از حد آزاد باشد. تغییر آزمایشی را منتشر نکنید؛ هدف سنجیدن قدرت gate است.

معیار پذیرش این کار

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

برای آماده‌کردن پروژهٔ کوچک و وظیفهٔ محدود، راهنمای شروع 123Coder را بخوانید. اجرای Pact یا هر چارچوب دیگر به تنظیمات مخزن شما وابسته است؛ این مقاله وجود یک قابلیت آمادهٔ تست قرارداد در محصول را ادعا نمی‌کند.

بازبینی منابع: ۱ اکتبر ۲۰۲۶. مثال سفارش و جلد تولیدشده با هوش مصنوعی صرفاً آموزشی‌اند.