تولید تست با هوش مصنوعی
نوشتن تست، کاری است که همه میدانند لازم است و کمتر کسی دوست دارد انجامش دهد. پس وعدهٔ تولید خودکارش جذاب است.
و اینجا یکی از بهترین کاربردهای این ابزارها هست — به شرطی که یک مسئلهٔ بنیادی را بفهمید و دورش بزنید.
مسئلهٔ بنیادی: تثبیت رفتار غلط
تستی که از روی کد موجود ساخته میشود، رفتار فعلی کد را تأیید میکند، نه رفتار درست را.
اگر تابعی باگ دارد، تست تولیدشده همان باگ را بهعنوان رفتار مورد انتظار ثبت میکند. حالا نهتنها باگ دارید، بلکه تستی دارید که جلوی اصلاحش را میگیرد — کسی که بعداً باگ را درست کند، تست را قرمز میبیند و فکر میکند اشتباه کرده.
این تنها مهمترین خطر این حوزه است و راهحلش ساده است:
تست تولیدشده را بخوانید و بپرسید: آیا این رفتاری است که باید باشد؟
نه «آیا تست میگذرد» — تست همیشه میگذرد، چون از روی همان کد ساخته شده.
کجا واقعاً ارزش دارد
حالتهای مرزی. بهترین کاربرد. آدم خسته، ورودی خالی و مقدار منفی و رشتهٔ خیلی بلند را فراموش میکند؛ ابزار نمیکند.
تست برای کد قدیمی بدون تست. سامانهای که سالها بدون تست کار کرده و هر تغییرش ترسناک است. اینجا حتی تستی که رفتار فعلی را تثبیت میکند مفید است — چون هدفتان این است که بدانید تغییر بعدی چیزی را نشکسته، نه اینکه رفتار درست را اثبات کنید. این را «تست مشخصه» مینامند و در نوسازی سیستم قدیمی جای مشخصی دارد.
دادهٔ آزمایشی. ساختن نمونههای واقعینما — نام و آدرس و کد ملی فارسی — کار کسلکنندهای است که ابزار خوب انجام میدهد.
تستهای تکراری با ورودی متفاوت.
تبدیل باگ گزارششده به تست. توصیف باگ را بدهید و تستی بگیرید که آن را نشان دهد — پیش از رفعش. این همان قاعدهای است که در استراتژی تست گفتیم و بیشترین بازده را دارد.
کجا ارزش ندارد
تست منطق کسبوکاری خاص. ابزار نمیداند قاعدهٔ تخفیف شما چیست، پس تستی میسازد که کد فعلی را تأیید میکند — و اگر کد غلط باشد، تست هم غلط است.
تستهای یکپارچگی پیچیده که به شناخت جریان داده در سامانهٔ شما نیاز دارند.
تستهای سرتاسری، که شکنندهاند و تولید خودکارشان شکنندهتر.
تست برای بالا بردن عدد پوشش. اینجا بدترین ترکیب اتفاق میافتد: تولید انبوه تستی که کد را اجرا میکند و ادعای معناداری نمیکند. پوشش بالا میرود و هیچ باگی گرفته نمیشود.
پوشش، سنجهٔ بدی است و با ابزار تولید خودکار، بدتر هم میشود — چون رسیدن به عدد ارزانتر شده.
روشی که کار میکند
ترتیبی که در پروژهها جواب داده:
۱. رفتار مورد انتظار را خودتان بنویسید، به زبان ساده. «اگر مشتری از سقف اعتبار گذشته باشد، سفارش رد میشود و پیام مشخصی میگیرد.»
۲. تست را از روی آن توصیف بسازید، نه از روی کد.
۳. تست را روی کد اجرا کنید. اگر رد شد، یا کد باگ دارد یا توصیف شما اشتباه بوده. هر دو حالت، کشف ارزشمندی است.
این ترتیب — توصیف اول، کد بعد — همان چیزی است که مسئلهٔ تثبیت رفتار غلط را حل میکند. و اتفاقاً به معیارهای پذیرشی که در تعریف اتمام کار گفتیم بسیار نزدیک است.
کیفیت تست را چطور بسنجیم
اگر میخواهید بدانید تستهایتان — تولیدی یا دستی — واقعاً ارزش دارند:
عمداً باگ وارد کنید و ببینید تستها میگیرند یا نه. یک شرط را برعکس کنید، یک عدد را عوض کنید. اگر همهٔ تستها سبز ماندند، تستهای شما چیزی بررسی نمیکنند.
این آزمون ساده، از هر عدد پوششی گویاتر است — و برای تستهای تولیدشده ضروریتر، چون آنها بهسادگی میتوانند بیادعا باشند.
نکات محصول فارسی
دادهٔ آزمایشی که ابزار تولید میکند معمولاً انگلیسی است. برای محصول فارسی، صریح بخواهید که این حالتها پوشش داده شوند:
- نام و آدرس فارسی با نیمفاصله.
- «ی» و «ک» عربی، که باید با معادل فارسی تطبیق بخورند.
- اعداد فارسی در ورودی.
- تاریخ شمسی، بهویژه اسفند و سال کبیسه.
- متن بلند فارسی که ممکن است چیدمان را بشکند.
فهرست کاملش در وب فارسی. ابزاری که این حالتها را نداند، تستی میسازد که در محیط انگلیسی سبز است و در محصول شما بیمعنی.
و یک هشدار دربارهٔ حجم
تولید آسان یعنی تست زیاد. و تست زیاد هزینه دارد: زمان اجرای خط لوله، نگهداری، و تستی که با هر تغییر کوچک میشکند.
قاعده: تست باید ارزشش را در برابر هزینهٔ نگهداریاش داشته باشد.
هزار تست تولیدشده که هیچ باگی نگرفتهاند و خط لوله را ده دقیقه کند کردهاند، بدهیاند نه دارایی. کمتر و بهتر، همیشه بهتر است.