AI For Test Generation: Where It Helps And Where It Lies
AI כותבת טסטים מהר. היא גם כותבת טסטים שנראים אמיתיים אבל בודקים את הדברים הלא נכונים.
אתם מדביקים פונקציה לתוך AI. שלושים שניות לאחר מכן, יש לכם שנים-עשר טסטים שעוברים. ציון ה-coverage שלכם עולה. אתם מרגישים פרודוקטיביים.
ואז באג מגיע לסביבת הפרודקשן. אתם מסתכלים על שנים-עשר הטסטים האלה ומבינים שאף אחד מהם לא היה תופס אותו.
ה-AI בדקה מה הקוד שלכם עושה, ולא מה הקוד שלכם אמור לעשות.
AI היא כלי שימושי, אבל אתם חייבים לדעת איך להשתמש בה.
Where AI wins:
- יצירת boilerplate כמו בלוקים של setup ו-teardown.
- כתיבת factory helpers ואובייקטי נתונים (data objects) חוזרים על עצמם.
- יצירת וריאציות רבות של תבנית טסט אחת טובה.
- טיפול במקרי קצה ברורים כמו null, מחרוזות ריקות או אפס.
Where AI fails:
- Implementation-based tests: היא כותבת טסטים שעוקבים אחרי מבנה הקוד במקום אחרי הלוגיקה העסקית. אם תבצעו refactor לקוד, הטסטים יישברו גם אם התוצאה עדיין נכונה.
- Shallow edge cases: היא מוצאת שגיאות ברורות אך מפספסת באגים ספציפיים לדומיין (domain-specific). היא לא מכירה את המוזרויות של אזורי הזמן שלכם, את אילוצי מסד הנתונים או את הכללים העסקיים הספציפיים שלכם.
- Brittle mocks: היא מבצעת mock לשירותים פנימיים שצריכים להישאר אמיתיים. זה הופך את התחזוקה של הטסטים לאיטית ואת השבירה שלהם לקלה במהלך refactors.
How to use AI without creating "test theater":
- הגדירו את החוזה (contract) תחילה. כתבו משפט אחד באנגלית פשוטה על מה הטסט חייב להוכיח. דוגמה: "An expired code must return the original amount."
- תנו את המשפט הזה ל-AI. תנו ל-AI לכתוב את הקוד, אבל אתם חייבים להיות הבעלים של הכוונה (intent).
- בצעו mock רק בגבולות (boundaries). השתמשו במופעים (instances) אמיתיים עבור המודולים הפנימיים שלכם. בצעו mock רק עבור APIs חיצוניים או מסדי נתונים.
- כתבו מקרה קצה אחד של הדומיין באופן ידני. ה-AI מטפלת במקרי הקצה ה"ברורים". אתם חייבים לטפל במקרי הקצה של "שלוש לפנות בוקר" שגורמים בפועל לתקלות בייצור.
אל תתנו ל-AI להחליט מה הטסט בודק. השתמשו בה כדי להקליד את הקוד, אבל אתם מספקים את הלוגיקה.
Source: https://dev.to/nazar_boyko/ai-for-test-generation-where-it-helps-and-where-it-lies-jhm