ביקורת על בדיקות שנוצרו על ידי AI: מחצית מה-CI הירוק לא מוכיחה כלום
בדיקה שעוברת מרגישה כמו הוכחה. בדרך כלל היא פחות ממה שאתם חושבים.
בדיקה קובעת שהקוד עושה את מה שהבדיקה מצפה לו. אם אותו כותב כותב גם את הקוד וגם את הציפייה, הציפייה מעוצבת על ידי הקוד. הבדיקה עוברת כי היא נכתבה כדי לעבור.
סימן וי (checkmark) ירוק מוכיח שהבדיקות שלכם מסכימות עם הקוד. הוא לא מוכיח שהקוד נכון.
הבעיה הזו גדלה כשסוכני AI שולחים Pull Requests שלמים. הם כותבים את המימוש ואת הבדיקות בבת אחת. סימן הוי לא הופך לאמין יותר כשהכותב משתנה.
בניתי את mirror_audit.py כדי למצוא את הפער הזה. הוא קורא את מקור הבדיקה באמצעות AST. הוא לעולם לא מריץ את הקוד. הוא מחפש שלושה דפוסים נפוצים:
- החישוב מחדש (The Recompute): הבדיקה משתמשת בנוסחה זהה לזו של הקוד. זהו f(x) == f(x) בתחפושת.
- הליטרל המוזהב (The Golden Literal): הבדיקה משתמשת במספר שהועתק מהרצה קודמת. זה נועל את הבדיקה למה שהקוד עשה ביום הראשון, כולל באגים.
- בדיקת עשן (The Smoke Test): הבדיקה בודקת אם התוצאה אינה
Noneאך חסרה לה הצהרה (assertion) אמיתית.
הרצתי את זה על שתי סוויטות (suites).
הסוויטה הראשונה תוכננה לשקף את המימוש. היא קיבלה יחס-שיקוף (mirror-ratio) של 50.0%. ה-CI נכשל. מחצית מהבדיקות לא נשאו שום אות (signal) עצמאי.
הסוויטה השנייה הייתה כנה. היא השתמשה במקרי קצה שליליים (negative cases) ובציפיות עצמאיות. היא קיבלה 0.0%. ה-CI עבר.
יחס-השיקוף אינו מודד את קצב הבאגים שלכם. הוא מודד חוסר באות עצמאי. הוא אומר לכם כמה מה-CI הירוק שלכם הוא בסך הכל הסוויטה שמהנהנת בהסכמה עם הקוד.
אם בדיקה מחשבת את אותה תוצאה שגויה כמו המימוש, הבדיקה נשארת ירוקה. אם בדיקה מצהירה על חוזה (contract) אמיתי, הבדיקה הופכת לאדומה ותופסת את הבאג.
הפסיקו להסתכל רק על כיסוי (coverage). שאלו את עצמכם אם הבדיקות שלכם באמת יכולות להיכשל מסיבה אמיתית.
Source: https://dev.to/alex_spinov/audit-ai-generated-tests-half-of-green-ci-proves-nothing-4bmb
Optional learning community: https://t.me/GyaanSetuAi
