איך מבקשים מסוכן קוד לתקן באג עם בדיקת רגרסיה?
בפוסט שלי על מעבר מ-ask agent → hope לתהליך עבודה הצגתי אבחון באגים כרצף: שחזור, צמצום, השערה, מדידה ותיקון. כאן אני מתמקד בראיה שנשארת אחרי התיקון: בדיקה שתופסת את הכשל הישן.
בקצרה
שומרים דרך לשחזר את הכשל לפני השינוי, מגדירים את ההתנהגות הרצויה ומבקשים תיקון קטן. אותה בדיקה צריכה לזהות את התקלה בקוד הישן ולעבור בקוד המתוקן, לצד בדיקות לתרחישי שגיאה.
מתחילים מכשל שניתן לשחזר
תיאור כמו "המסך לפעמים נשבר" משאיר לסוכן יותר מדי אפשרויות. צרפו קלט, הפעולה שבוצעה, התוצאה הצפויה והתוצאה בפועל. ציינו גרסה וסביבה כשאלה משפיעות על ההתנהגות. הסירו מידע פרטי מהדוגמה.
אם הכשל תלוי בזמן או בשירות חיצוני, תעדו מה ידוע ומה עדיין השערה. קושי בשחזור הוא מידע חשוב, לא סיבה להציג תיקון כאילו התקלה כבר הובנה.
שומרים את הכשל לפני שנוגעים בקוד
בקשו מהסוכן להוסיף בדיקה ממוקדת או פקודת שחזור ולרוץ על הגרסה הישנה. שמרו את הפלט ואת גרסת הקוד. בדיקה שכתובה רק אחרי התיקון יכולה לבדוק את מה שהסוכן מימש במקום את מה שהמשתמש צריך.
המחשה: פונקציה אמורה לקרוא קובץ הגדרות, אבל טיפול חדש בחריגות מחזיר מילון ריק גם כשהקובץ חסר. בדיקת הרגרסיה צריכה לדרוש את התנהגות השגיאה שסוכמה, ולא להסתפק בכך שהפונקציה מחזירה מילון. זו דוגמה מוצעת, לא תיאור תקלה אצל לקוח.
מפרידים בין הסביבה לבין ההתנהגות
בתיעוד pytest, fixture בשם tmp_path נותן תיקייה זמנית נפרדת לכל בדיקה. אפשר ליצור בה קובץ תקין, קובץ פגום ונתיב שאינו קיים, בלי להשתמש בקבצים אישיים או בתיקיית העבודה הרגילה.
הכלי monkeypatch מאפשר לשנות באופן זמני משתני סביבה, מאפיינים או התנהגות של פונקציה. השינויים מתבטלים בסיום הבדיקה או ה-fixture. הוא שימושי לבידוד תלות חיצונית, אבל התוצאה עדיין תלויה בכך שהתחליף מייצג נכון את הממשק.
בדיקה עם תחליף לשירות אינה בדיקת חיבור לשירות האמיתי. ציינו בנפרד מה אומת מקומית ומה עדיין דורש בדיקת אינטגרציה. בתיקיות זמניות השתמשו בברירות המחדל הבטוחות. אפשרות כמו basetemp מוחקת את תוכן התיקייה שהוגדרה לה, ולכן אינה מתאימה לנתיב עם חומר שרוצים לשמור.
נותנים לסוכן גבולות לתיקון
אפשר להשתמש בבקשה הזו כהמחשה:
קודם שחזר את התקלה ושמור בדיקה שנכשלת מהסיבה הנכונה. הסבר את ההשערה והצע תיקון קטן. שמור על הממשק ועל התנהגות השגיאות שסוכמה. בסיום הראה diff, פקודות ותוצאות בפועל, ומה עדיין לא נבדק. שינוי נוסף מחוץ לתיקון דורש החלטה נפרדת.
הגבולות מונעים פתרון רחב מדי: החלפת ספרייה, שינוי פורמט פלט או הסתרת חריגה עשויים לגרום לבדיקה לעבור בלי לפתור את הצורך המקורי.
בודקים שהבדיקה באמת מבחינה בין הגרסאות
ודאו שהבדיקה נכשלת על הקוד הישן בשל התקלה, ולא בגלל תלות חסרה או שגיאת התקנה. אחר כך הריצו אותה על התיקון. אם אפשר, בדקו זמנית את הבדיקה גם מול הגרסה הישנה כדי לוודא שהיא עדיין תופסת את הכשל.
הריצו גם בדיקות סמוכות לממשק שהשתנה. תיקון לקריאת קובץ צריך להתייחס לקלט תקין, קובץ חסר וקלט פגום לפי החוזה של הפונקציה. הרשימה תלויה בתקלה, ואינה תחליף להבנת הקוד.
מחזירים תוצאה עם גבולות ראיה
בסיום שמרו את גרסת הקוד, פקודות ההרצה, התוצאה והמגבלות. כתבו "הבדיקות האלה עברו" במקום "הכול עובד". שינוי שמכסה תקלה מקומית עדיין יכול להשאיר שאלות על סביבה אחרת, נתונים גדולים או שירות חיצוני.
התפקיד של בדיקת רגרסיה הוא להשאיר ראיה שאפשר להריץ גם אחרי השיחה עם הסוכן. היא עוזרת לשמור את התיקון כשהקוד ממשיך להשתנות.
מקורות ופרטים נוספים
ההמלצות הן דרך עבודה מוצעת. המקורות הציבוריים וההמחשות מובחנים מטענות על ניסיון ותוצאות בפועל.
שאלות נפוצות
האם מספיק שהסוכן כתב בדיקה שעוברת?
צריך לוודא שהבדיקה תופסת את התקלה בגרסה הישנה ועוברת על התיקון. פלט ירוק לבדו אינו מוכיח זאת.
איך בודקים קבצים בלי לגעת במידע פרטי?
אפשר ליצור קלטים סינתטיים בתיקייה נפרדת לכל בדיקה באמצעות tmp_path. בוחרים דוגמאות שמייצגות את הממשק.
האם mock מחליף בדיקת אינטגרציה?
הוא מבודד תלות ומאפשר בדיקה ממוקדת. החיבור לשירות האמיתי נשאר בדיקה נפרדת, וצריך לציין אם לא בוצעה.