تولید و آزمایش پذیری واحد تست: تست قوی با هوش مصنوعی

سود:

• توانایی جلوگیری از پذیرش رفتار اشتباه توسط هوش مصنوعی به عنوان "درست" با محاسبه مقدار مورد انتظار در تست های واحد مستقل از قانون پذیرش
• امکان چاپ تست های سریع، مستقل و قابل تکرار با استفاده از اصول AAA و FIRST و تمسخر وابستگی های خارجی
• امکان تست تست های دارای جهش (شکن کردن کد) و تشخیص کدهای سخت تست به عنوان بوی طراحی

بزرگ‌ترین و سریع‌ترین لایه هرم آزمایش، تست واحد است - آزمایشی که یک تابع یا قطعه کوچک کد را جدا از هر چیز دیگری تأیید می‌کند. هزاران تست واحد در چند ثانیه اجرا می‌شوند و در حالی که کد هنوز روی صفحه برنامه‌نویس است، باگ می‌گیرند. هوش مصنوعی (AI) شاید در تولید تست‌های واحد مهارت بیشتری داشته باشد: شما به آن یک عملکرد می‌دهید، هوش مصنوعی ده‌ها تست را تولید می‌کند. اما همین راحتی، بزرگ‌ترین دام را به وجود می‌آورد: هوش مصنوعی به راحتی آزمایش‌هایی را تولید می‌کند که «سبز می‌درخشند اما چیزی را تأیید نمی‌کنند» یا رفتار فعلی (شاید معیوب) کد را به‌عنوان «درست» می‌پذیرند. در این بخش شما یاد خواهید گرفت که چگونه تست های واحد محافظ واقعی را با هوش مصنوعی بنویسید و رابطه بین کد قابل آزمایش و هوش مصنوعی را یاد خواهید گرفت.

ویژگی های یک آزمون واحد خوب: اول

تست‌های واحد خوب از اصول اول پیروی می‌کنند: سریع، مستقل (آزمون‌ها نباید به یکدیگر وابسته باشند)، تکرار شونده (تکرارپذیر – نتیجه یکسان در هر محیطی)، اعتبارسنجی خودکار (مصوب/ناقص)، به موقع (به‌موقع). هنگام انجام تست های تولید هوش مصنوعی، این اصول را به خود یادآوری کنید. به طور خاص بخواهید که آزمون به دنیای خارج (پایگاه داده واقعی، شبکه، ساعت) وابسته نباشد تا «مستقل» و «تکرارپذیر» باشد.

الگوی AAA و ادعای رسا

یک تست واحد جامد از ساختار AAA پیروی می کند: ترتیب (آماده کردن - تنظیم ورودی ها و وابستگی ها)، عمل (اجرا - فراخوانی تابع تحت آزمایش)، Assert (تأیید - مقایسه نتیجه با مقدار مورد انتظار). مورد انتقادی، ادعا است. رایج ترین اشتباهی که هوش مصنوعی مرتکب می شود این است که ادعا را از خروجی کد مورد آزمایش استخراج می کند - منطق "هر چیزی که کد برمی گرداند درست است". این باعث می شود که آزمون بی معنی باشد. راه صحیح تعیین مقدار مورد انتظار به طور مستقل است (از معیارهای پذیرش، آن را به صورت دستی محاسبه کنید).

توجه: اگر به هوش مصنوعی بگویید "برای این تابع یک تست بنویسید"، AI ممکن است تابع را اجرا کند و خروجی آن را به صورت "مورد انتظار" بنویسد. این تست حتی اگر تابع نادرست باشد، انجام می شود. در عوض، بگویید "نتایج مورد انتظار را طبق این قوانین محاسبه می کنید، به خروجی فعلی تابع اشاره نکنید."

تمسخر، خرد و وابستگی

تست واحد نیاز به جداسازی دارد. اگر عملکرد شما به یک پایگاه داده یا API بستگی دارد، در آزمایش با اشیاء ساختگی (mock/stub – یک جایگزین کنترل‌شده و ساختگی برای وابستگی واقعی) جایگزین می‌شوند. این باعث می شود تست سریع، مستقل و قابل تکرار باشد. هوش مصنوعی می تواند نصب ساختگی ایجاد کند. اما مراقب تمسخر بیش از حد باشید: اگر همه چیز را مسخره کنید، آزمایش فقط «آنچه را که مسخره برمی‌گرداند» تأیید می‌کند، نه منطق واقعی را. تعادل: دنیای بیرون را تقلید کنید، منطق واقعی تحت آزمایش را اجرا کنید.

تست پذیری و هوش مصنوعی

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

آزمون های پارامتری و تنوع داده ها

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

اما یک تله در اینجا نیز وجود دارد: هوش مصنوعی تمایل دارد نتایج مورد انتظار را در جدول تولید شده از کد مورد آزمایش استخراج کند. این خطا در تست پارامتری شده حتی خطرناک تر است، زیرا یک منطق نادرست تنها ده ها خط را باطل می کند. بنابراین، همیشه ستون نتیجه مورد انتظار را به طور مستقل طبق قانون پذیرش محاسبه کنید و حداقل چند ردیف را به صورت دستی تأیید کنید. همچنین برای ستون توضیحات بخواهید "هر ردیف چه چیزی را نشان می دهد"؛ بنابراین وقتی یک ردیف شکسته می شود، فوراً می بینید که کدام حالت شکسته شده است.

نکته: عمداً یک "ردیف تله" را به جدول تست پارامتری شده اضافه کنید - یعنی عمداً نتیجه را اشتباه تایپ کنید. اگر هنگام اجرای تست آن خط قرمز نشود، آزمایش شما در واقع آن وضعیت را تأیید نمی کند. این یک بررسی سریع تقلبی است.

اعلان ضعیف / اعلان قوی

ضعیف: "یک تست واحد برای این تابع بنویسید."

قوی: تست‌های واحد [زبان/چارچوب] را برای تابع "taxCalculate(مبلغ، نرخ) بنویسید. قانون پذیرش: نتیجه = مقدار * نرخ، به 2 اعشار گرد می‌شود؛ مقدار منفی یا نرخ خطا را نشان می‌دهد؛ اگر نرخ 0 باشد، 0 را برمی‌گرداند. از ساختار AAA استفاده کنید. مقادیر مورد انتظار را به صورت دستی محاسبه کنید (خروجی‌های مورد انتظار را مطابق با این قوانین، خروجی بسیار منفی، موارد منفی، تابع 0 را مرجع نکنید. بزرگ، گرد تا اعشار، اجازه دهید نام هر آزمون، وابستگی خارجی را توصیف کند.

اعلان قدرتمند؛ این قانون پذیرش، انتظارات ارزش مورد انتظار مستقل، ساختار و موارد لبه را ارائه می دهد. بنابراین، آزمون نگهبان قانون می شود، نه آینه رمز.

جدول کیفیت تست واحد

علامت

تست بد (اعتماد جعلی)

تست خوب

ادعا کردن

هیچ یا "تهی نیست"

ارزش بتن مورد انتظار

منبع ارزش مورد انتظار

خروجی تابع

قانون پذیرش / محاسبه دستی

اعتیاد

DB/شبکه/ساعت واقعی

عایق شده با ساختگی/خرد

مورد لبه

فقط جاده شاد

حد، منفی، خطا

وقتی کد را می شکنی

سبز باقی می ماند

قرمز می شود

نام

test1, testMethod

قاعده ای را که تایید می کند را شرح می دهد

چهار قالب قابل کپی

1) تست واحد قانون محور:

نقش شما: مهندس ارشد آزمون نرم افزار. یک آزمون واحد روی تابع زیر با [زبان/چارچوب] بنویسید: [امضا]. قوانین پذیرش: [قوانین].- از ساختار AAA استفاده کنید.- مقادیر مورد انتظار را به صورت دستی بر اساس این قوانین محاسبه کنید. خروجی فعلی تابع را ارجاع ندهید. - حد، منفی، خطا و مسیر مبارک را با تست های جداگانه پوشش دهید. - اجازه دهید هر نام آزمون قاعده ای را که تأیید می کند توصیف کند. - وابستگی های خارجی را مسخره کنید. منطق واقعی را عملی کنید.

2) کنترل مقاومت در برابر جهش:

این تست های واحد را بررسی کنید. 5 تغییر جزئی را که می‌توانم در کد مورد آزمایش انجام دهم (a - به جای +، a >= به جای >، یک تغییر مرز) فهرست کنید و به من بگویید برای هر کدام کدام یک از این تست‌ها قرمز می‌شوند؟ اگر هیچ کدام برگردانده نشد، آزمایش کافی نیست. کد + تست: [ چسباندن]

3) بررسی آزمایش پذیری:

چرا نوشتن تست واحد برای این تابع دشوار است؟ اعتیاد پنهان، وضعیت جهانی، عوارض جانبی، آیا مسئولیت های زیادی وجود دارد؟ پیشنهاد حداقل refactoring برای قابل آزمایش کردن. رفتار را تغییر ندهید کد: [چسباندن]

4) تکمیل سناریو ناقص:

عملکرد زیر و تست های موجود ارائه شده است. لیست کنید که کدام رفتار/زبان لبه هرگز آزمایش نشده است (شکاف دامنه) و برای هر کدام یک تست اضافه کنید. تابع + تست: [رب]

سه کیف کوچک

مورد 1 - تست بازتاب کد. یک توسعه‌دهنده از هوش مصنوعی خواسته بود که آزمایشی برای عملکرد گرد کردن بنویسد. 10 تست سبز بود. در واقع، تابع در جهت اشتباه گرد می شد، اما هوش مصنوعی مقادیر مورد انتظار را از خروجی تابع گرفته بود، بنابراین تست ها خطا را "درست" در نظر گرفتند. هنگامی که مقادیر مورد انتظار به صورت دستی با الگوی "قاعده محور" محاسبه شد، 4 تست قرمز شد و خطای واقعی آشکار شد.

مورد 2 - ارزش کنترل جهش. یک تیم بر روی 45 آزمون واحد تکیه کرد. 20 تغییر جزئی در کد با "بررسی استحکام جهش" انجام شد. آزمایشات فقط 11 مورد از آنها را گرفت. 9 اختلال باقی مانده بی سر و صدا گذشت. تیم تست های ضعیف را تقویت کرد. یک خطای محاسباتی واقعی توسط این آزمایش‌های پیشرفته در نسخه بعدی مشاهده شد.

مورد 3 - آزمایش ناپذیری یک بوی طراحی است. هوش مصنوعی نمی‌توانست آزمایش‌هایی را برای یک تابع سفارش بنویسد، دائماً به پایگاه داده واقعی نیاز داشت. الگوی "بررسی قابلیت آزمایش" نشان داد که این تابع دسترسی به پایگاه داده را تعبیه کرده است. وقتی تزریق وابستگی حذف شد، می‌توان تست‌ها را نوشت و کد پاک‌تر شد.

اشتباهات رایج

• استخراج مقدار مورد انتظار از کد هوش مصنوعی خروجی تابع را به عنوان "درست" می پذیرد. تستی که کد معیوب را تایید می کند.
• بدون ادعا یا با ادعای بی اهمیت تست کنید. منطق "او خطا نکرد، پاس کرد"; چیزی رو تایید نمیکنه
• تمسخر افراطی تمسخر همه چیز و آزمودن تنها چیزی که مسخره باز می گرداند. منطق واقعی آزمایش نمی شود.
• فقط جاده شاد دور زدن حالت های حد، منفی و خطا.
• تست نشدن با شکستن کد. اعتماد به سبز بدون بررسی جهش.
• نادیده گرفتن آزمایش ناپذیری تشخیص ندادن و اصلاح طراحی بد به جای فشار دادن به آزمایش سخت.

به طور خلاصه

تست های واحد سریع ترین و بزرگترین لایه هرم آزمایش هستند. اشتباه را در ارزان ترین لحظه می گیرد. هوش مصنوعی بسیار قادر به تولید تست های واحد است، اما بزرگترین دام آن نوشتن تست هایی است که با استخراج مقدار مورد انتظار از خود کد، رفتار نادرست را "درست" فرض می کنند. راه حل: قوانین پذیرش را ارائه دهید، مقادیر مورد انتظار را به صورت دستی محاسبه کنید، اصول AAA و FIRST را اجرا کنید، دنیای خارج را مسخره کنید و منطق واقعی را اجرا کنید، و هر تست را با جهش (شکستن کد) آزمایش کنید. کدی که آزمایش آن دشوار است یک نشانه طراحی است که نیاز به تعمیر دارد.

وظیفه کاربردی

تابعی را انتخاب کنید که حاوی یک قانون تجاری از پروژه خودتان باشد. قوانین پذیرش را بنویسید و تست های هوش مصنوعی را با الگوی "تست واحد قانون محور" بنویسید. مقادیر مورد انتظار را به صورت دستی محاسبه کنید. سپس "بررسی استحکام جهش" را اعمال کنید: حداقل 5 شکست کوچک در کد ایجاد کنید و اندازه گیری کنید که چند تست قرمز می شوند. اضافه کردن تست جدید برای فسادهای کشف نشده. گزارش دهید که چند اختلال ایجاد شده است (مانند نمره جهش).

چک لیست

• [ ] من قوانین پذیرش را ارائه کردم و مقادیر مورد انتظار را به صورت دستی محاسبه کردم.
• [ ] مطمئن شدم که تست ها مقدار مورد انتظار را از کد استخراج نکرده اند.
• [ ] من آزمایش مستقل را با پیروی از دستورالعمل های AAA و FIRST ایجاد کرده ام.
• [ ] وابستگی های خارجی را مسخره کردم و منطق واقعی را اجرا کردم.
• [ ] موارد محدود، منفی و خطا را پوشش دادم.
• [ ] با شکستن کد (جهش) ثابت کردم که تست ها واقعا محافظت می کنند.