در یک پروژه مقدماتی API، موفق بودن یک درخواست کافی نیست؛ باید رفتار برنامه در برابر مقدار ضروریِ غایب، خالی یا با نوع نادرست هم بررسی شود. مثال این مطلب در Python، مستقل از framework است و فقط یک dictionary ورودی را بررسی می‌کند. رسیدگی به HTTP بر عهده web framework اطراف این منطق است.
در function با نام validate_name، مقدار name از dictionary خوانده می‌شود. اگر این مقدار از نوع str نباشد یا پس از اجرای strip خالی شود، خروجی شامل پیام «name must be a non-empty string» و مقدار وضعیت 400 است. در غیر این صورت، نام با حذف فاصله‌های ابتدا و انتها، همراه با مقدار وضعیت 200 برگردانده می‌شود.
تست چهار ورودی نامعتبر را بررسی می‌کند: dictionary بدون name، نام با مقدار خالی، نامی که فقط شامل فاصله است و نام با مقدار عددی 123. برای همه این حالت‌ها، مقدار وضعیت باید 400 باشد و خروجی باید کلید error داشته باشد. یک بررسی دیگر هم مشخص می‌کند که ورودی « Asha » باید به «Asha» تبدیل شود و مقدار وضعیت 200 داشته باشد.
نبودن کلید و خالی بودن مقدار، دو ورودی متفاوت‌اند، اما هر دو با Contract این مثال ناسازگارند. تست‌ها این تصمیم را ثبت می‌کنند تا تغییر بعدی نتواند بدون آشکار شدن در تست، عدد را به‌عنوان نام بپذیرد.
این function فرض می‌کند ورودی از قبل dictionary است. بنابراین endpoint باید جداگانه به JSON نامعتبر، نوع غیرمنتظره در سطح اصلی ورودی و بررسی هویت و مجوز دسترسی رسیدگی کند. محدودیت طول نام هم باید بر اساس نیاز برنامه تعیین شود و داده‌های تست نباید شامل اطلاعات شخصی واقعی باشند.
تمرین پیشنهادی مطلب، اتصال این منطق به یک endpoint کوچک برای فرم و افزودن Integration Test است؛ تستی که درخواست واقعی بفرستد و پاسخ مورد انتظارش روشن باشد. همین انتظارهای مشخص باید معیار بررسی کد تولیدشده با AI باشند، نه صرفاً اینکه کد اجرا می‌شود.
