יצירת בדיקות יחידה באמצעות AI: כיסוי קוד אוטומטי

יצירת בדיקות יחידה באמצעות AI: היכן הכיסוי נשבר

כיסוי שורות משקר: הדוח מציג 80%, אבל ב release נופלים תרחישים שאינם נראים בו. המדד סופר שורות שהורצו, ולא ענפי לוגיקה שנבדקו — יציאות מוקדמות, אופרטורים טרנריים ובלוקים לטיפול בחריגות נשארים בלי בדיקה. זהו צוואר הבקבוק של הכיסוי: המספר עולה, הביטחון לפני העלאה לא.

אזור נוסף של שחיקה — שינויים בקוד ישן. השינוי מוסיף תנאי אחד, האחוז הכולל לא זז, והענף החדש לא נבדק בכלל. סף לקוד חדש ב-SonarQube מחשב כיסוי לפי השורות שהשתנו — שם מיד נראה שכיסוי הקוד האוטומטי מפגר אחרי קצב השינויים, ושרגרסיות ב-release מגיעות מהדלתא, לא מה-legacy.

האזור השלישי — טיפול בשגיאות: timeouts, ניסיונות חוזרים, כשלים חלקיים של שירותים חיצוניים, תשובות ריקות ופסולות. לשחזר אותן ידנית זה ארוך ולא נוח, ולכן לרוב פשוט עוקפים אותן — ובפרודקשן דווקא הן מתפוצצות.

הרביעי — חיבורים אינטגרטיביים: סריאליזציה, חוזים בין שירותים, מיפוי בין שכבות לבין אחסון. הבדיקות בתוך המודול ירוקות, אבל במפגש הפורמט של השדה מתפצל או שערך ריק הולך לאיבוד. בהמשך נפרק כיצד יצירת בדיקות יחידה באמצעות AI סוגרת את ארבעת המקומות האלה שלב אחר שלב.

מה משתנה אחרי ההטמעה: כיסוי, ריוויו, כשלים

האפקט הראשון נראה בשער האיכות לקוד חדש. בדיקות שנוצרו מופיעות באותו שינוי שבו נמצאת הלוגיקה, ולכן את הכיסוי לא "משלימים" במשימה נפרדת כעבור חודש: שיעור השורות שנבדקו בשינוי עצמו עולה משליש ל-70–80% במקום ממוצע מטושטש על כל המאגר.

את המדד רואים ב-SonarQube לצד שאר מדדי הבנייה, כך שצמיחת כיסוי הקוד היא לא דוח, אלא תנאי מדיד למעבר הבנייה.

השני — זמן הריוויו על שינויים. המבקר מפסיק להריץ ידנית תרחישים מובנים מאליהם: קלט ריק, גבולות טווח, שגיאה בקריאה חיצונית — הם כבר מעוגנים בבדיקה ונופלים בעצמם. הדיון עובר לחוזים ולארכיטקטורה במקום "למה על ערך ריק הכול קורס", ושינוי טיפוסי מסתכם בעשרות דקות במקום שעות.

השלישי — סוג הכשלים שמפסיק להגיע לסטנד ולפרודקשן. רגרסיות אחרי תיקונים ממוקדים נתפסות בשלב הבנייה: הבדיקה בגבול המודול מאדימה לפני ההעלאה, ולא בתורנות. שיעור הרולבקים במחזור ה-release יורד, ויציבות ה-release מפסיקה להיות תלויה בשאלה מי בדיוק בתורנות היום.

הסתייגות שבלעדיה האפקט לא מחזיק: הבדיקות חייבות להיות ברות-תחזוקה. אנחנו מייצרים אותן לכל שינוי, ולא "על כל הפרויקט בבת אחת", לא משכפלים תרחישים חופפים ולא מקבעים בדיקות לפרטי המימוש — אחרת כעבור חודשיים מוחקים אותן, והכיסוי חוזר לרמה ההתחלתית.

השוואת מצבים: הרצה מקומית, צינור בנייה, קונטור ייעודי

שלושת מצבי ההרצה נבדלים לא באיכות היצירה, אלא במקום שבו המודל פועל ולאן יוצא קוד המקור. הרצה מקומית משאירה את הקוד במכונת המפתח, צינור הבנייה מייצר בדיקות על כל שינוי, וקונטור ייעודי נפרס בתוך הרשת שלכם ומשרת כמה מאגרים בבת אחת.

המצבים לא שוללים זה את זה: התרחיש העובד הוא יצירה מקומית על ענף המפתח, הרצה בצינור הבנייה לרגרסיה, וקונטור ייעודי למודולים עם גישה מוגבלת. המגבלות מוסרות לא בבחירה של אפשרות אחת, אלא בחלוקת המשימות ביניהן.

שלבי ההטמעה: מאודיט של מאגר הקוד ועד מסירה

הטמעת יצירת הבדיקות מתחילה לא בכלי, אלא בסימון מאגר הקוד: היכן בדיקות אוטומטיות יתנו משמעות, והיכן ייתקלו בתלויות נסתרות ובתופעות לוואי. סדר העבודה זהה גם למונוליט וגם לאוסף שירותים — משתנה רק היקף האודיט.

1. אודיט של מאגר הקוד. מסמנים מודולים לפי צמידות, שיעור הסתעפויות וקיום חוזים מפורשים. בנפרד מסמנים קוד עם קריאות חיצוניות ומצב גלובלי — שם היצירה דורשת הגדרה ידנית של סטאבים.

2. תכנית כיסוי. קובעים סדרי עדיפויות: נתיבים קריטיים, מטפלי שגיאות, ערכי גבול. לכל בלוק מקבעים יעד כיסוי, כדי שהתוצאה תימדד ולא תידון לפי טעם.

3. הגדרת כללי היצירה. מגדירים תבניות, סגנון שמות, מבנה קבצים ומסגרת הבדיקות שבה משתמשים. רושמים אילו תלויות מוחלפות ואילו נבדקות על נתונים אמיתיים, ומה באופן עקרוני לא מכוסה אוטומטית.

4. בדיקה על מדגם מודולים. מריצים את היצירה על 10–20 מודולים מייצגים ומשווים לבדיקות שנכתבו ידנית. בודקים את שיעור הבדיקות שעוברות מהרצה ראשונה ואת הזמן שהמבקר משקיע בבדיקה שנוצרה אחת.

5. הטמעה בצינור הפיתוח. היצירה רצה על קבצים שהשתנו, הבדיקות עוברות אותו ריוויו כמו בדיקות ידניות, ונפילת בדיקות חוסמת מיזוג ענף.

6. מסירת תיעוד והדרכה. מוסרים תיאור כללים, קונפיגורציה וניתוח מקרים שנויים במחלוקת. מקיימים סקירות על מודולים אמיתיים, כדי שהמהנדסים יוכלו לשנות את כללי היצירה בעצמם, בלי התמיכה שלנו.

קריטריון סיום השלב — הצוות מוסיף מודול חדש לתכנית הכיסוי ומקבל בדיקות בעלות משמעות בלי מעורבות של הספק.

מה נשאר אצל הצוות: קונפיגורציות, תכניות, נהלים

יצירת בדיקות יחידה חיה במאגר, ולא בחשבון שלנו. אחרי המסירה נשארים אצל הצוות ההגדרות, מפת הכיסוי, כללי בחירת המודולים, התיעוד ונוהל הליווי — בלי הסט הזה הפתרון מחזיק עד השינוי הארכיטקטוני הגדול הראשון, ואחר כך הבדיקות מתיישנות, החריגים מצטברים, ואת ההרצה מפסיקים לקרוא.

• קונפיגורציות של מחולל הבדיקות — ספי כיסוי לפי מודולים, כללי חריגים (קוד שנוצר, מיגרציות, עטיפות של שירותים חיצוניים), מצבי הרצה. הסף למודול מסוים משתנה בלי מעורבות שלנו.
• מפת כיסוי המודולים — לכל מודול: אילו ענפים מכוסים, היכן נבדק רק התרחיש המוצלח, והיכן הפער. נבנית מחדש בכל הרצה, ולא ידנית פעם ברבעון.
• כללי בחירת המודולים — קריטריונים לכניסה ליצירה: מורכבות הסתעפות, תדירות שינויים, מקום בשרשרת הקריאות. סדרי העדיפויות נבחנים מחדש ככל שהקוד גדל.
• נוהל עדכון הבדיקות — מה עושים כשבדיקה שנוצרה נפלה: לעדכן את הציפייה, לתעד את הפגם או להכניס לחריגים. עם אחראי וסדר פעולות.
• תיעוד הבדיקות — הרצה מקומית ובבנייה, הרכב הסטים, קריאת דוח הכיסוי. מהנדס חדש נכנס לצינור בלי התכתבות איתנו.
• מסירת הפתרון — גישות למאגר הבדיקות ולהגדרות ההרצה, סקירה על מודול חי, רשימת הבדיקות לפני השינוי העצמאי הראשון. הצוות מריץ ומתקן בנוכחותנו.

מקרה בוחן: שירות מורשת — הכיסוי גדל פי שלושה

שירות חישובים מורשת חי בפרודקשן כתשע שנים: בדיקות נכתבו נקודתית, חלקן התפצל מהקוד והושבת. כל שינוי במודול ישן חייב הרצה ידנית של תרחישים על הסטנד, והרגרסיה צפה רק אחרי ההעלאה.

נקודת ההתחלה

כיסוי הענפים עמד על 18%, וגם זאת JaCoCo ספר רק על מודולים שבהם הבדיקות בכלל שרדו — השאר נשאר אטום. על הסטנד נרשמו באופן קבוע 18–22 כשלים בשבוע, וההתאוששות אחרי שינוי במודול ישן ארכה 4–5 שעות, שמתוכן יותר ממחצית הלכו לאיתור הסיבה.

מה שינו ומה קיבלו

תחילה ניתוח סטטי דירג את המודולים לפי תדירות שינויים וצמידות — היצירה הלכה למקום שבו מחיר הרגרסיה מקסימלי.

המודל הציע בדיקות לפי חתימות, סוגי החזרה והסתעפויות, בדיקת מוטציות פסלה סטים שעוברים על כל מימוש, והמהנדס אישר רק את אלה שבודקים את החוזה של המודול, ולא את ההתנהגות הנוכחית שלו.

קריאות חיצוניות הוחלפו בתשובות מוקלטות, ולכן הסט הפך לדטרמיניסטי והפסיק להיות תלוי בסטנד. כיסוי הענפים עלה ל-56%, מספר הכשלים על הסטנד ירד ל-5–7 בשבוע, וזמן ההתאוששות אחרי שינויים במודול ישן הצטמצם ל-40–50 דקות.

מה עושים אם מאגר הקוד כבר מכוסה בבדיקות מיושנות?

כיסוי מורשת הוא כמעט תמיד פורמלי: או שההרצה אדומה ולמדו להתעלם ממנה, או שהיא ירוקה אבל בודקת לא התנהגות אלא פרטי מימוש. האמון בהרצות יורד לאפס — רגרסיות צפות בפרודקשן, והשינויים עולים "בעין". נפרק באיזה סדר לעבור על סט כזה.

קודם כל אינבנטריזציה ושלוש סלסילות: בדיקות שנופלות כששוברים את הלוגיקה בכוונה; בדיקות שמקובעות למימוש — מתודות פרטיות, סדר קריאות, תמונות מצב מדויקות; ולא-יציבות, שתלויות בסביבה או בסדר ההרצה. נקודת הייחוס היא לא אחוז הכיסוי, אלא שיעור הבדיקות שמגיבות לשגיאה שהוכנסה.

בשלב הבא מפרידים בין הערך לבין התשתית. תרחישים, נתוני בדיקה וערכי גבול שנאספו מפגמים קודמים — מעבירים אותם, זה הנכס היקר ביותר בסט. את התשתית כותבים מחדש: הרצה, בידוד נתונים, הכנת סביבה — בדיוק בגללה הסט הישן מאדים על קוד שלא השתנה.

סדר הבנייה מחדש: קודם מייצבים את ההרצה — בדיקות לא-יציבות עוברות להסגר עם בעלים ומועד, אבל לא נמחקות בשקט. אחר כך סוגרים נתיבים קריטיים: הרשאות גישה, חישובים, מיגרציות נתונים. ורק אז מרחיבים את הכיסוי, ומייצרים בדיקות מההתנהגות העדכנית של הקוד.

האמון בהרצות מחזיק על כלל אחד: תוצאה אדומה חוסמת מיזוג, ירוקה משמעה "ההתנהגות לא השתנתה". לכן הבדיקות דטרמיניסטיות — נתונים מבודדים, זמן קבוע, בלי פניות לרשת. אז הסט גדל בזכות מחיקת כפילויות, ולא על חשבון זמן ההרצה.

ספקות נפוצים: איכות, התראות שווא, תחזוקה

ספקות לפני הטמעה מסתכמים בדרך כלל בארבע שאלות: האם הבדיקות שנוצרו פורמליות, האם הבנייה תתחיל ליפול סתם, האם קוד המקור ידלוף, ומי אחראי לסט אחרי שהמחבר עוזב. כל אחת מהן נבדקת באופן מדיד, ולא בהבטחות.

את המדד המרכזי אנחנו רואים לא בשיעור השורות המכוסות — קל לאסוף אותו בבדיקות שלא בודקות דבר — אלא בעמידות למוטציות ובשיעור ההרצות הלא-יציבות.

מאיפה מגיעות התראות שווא ואיך אתם מסלקים אותן?

המקור לרוב הנפילות הכוזבות הוא אי-דטרמיניזם: זמן, ערכים אקראיים, סדר מעבר על אוספים, שירותים חיצוניים. מחוללים מקובעים בזרע, זמן ורשת מוחלפים בכפילים מבוקרים, הנתונים מוכנים במסד מבודד ומתגלגלים אחורה אחרי ההרצה. הבדיקה משוחזרת באופן זהה אצל המפתח ובצינור הבנייה.

הקוד יוצא לשרתים חיצוניים?

פורסים בתוך הקונטור שלכם: המודל פועל על המשאבים שלכם, קוד המקור והיסטוריית השינויים לא יוצאים מהפרימטר, ופניות יוצאות נחסמות ברמת הרשת. גישה — לפי התפקידים שלכם, הארטיפקטים והלוגים נשארים אצלכם, ומאגרים שאסור להציג אפילו למודל מקומי מוחרגים במדיניות.

מה קורה עם הליווי כשהמחברים יעזבו את הפרויקט?

סט הבדיקות מתיישן בזמן ריפקטור ודורש בעלים. מוסרים נוהל עדכון ומחיקה של בדיקות, הרכב המדדים ונקודות הבקרה בצינור הבנייה — הצוות מנהל את הסט בעצמו. לפי הרצון נשארים בליווי עם זמן תגובה קבוע לנפילות.

נדון במשימה: מה נדרש מכם כדי להתחיל

כדי לחזור עם הערכה ותכנית עבודה, ולא עם מילים כלליות, אנחנו צריכים הקשר על הקוד ועל תהליך הפיתוח. להלן נתוני הקלט להערכה: ככל שיותר סעיפים מכוסים, כך מדויקים יותר הלוחות זמנים ופחות הבהרות בתחילת הפרויקט.

• המאגר או חלק ממנו שאנחנו מתכננים לכסות: שפה, מסגרת, מבנה המודולים ונקודות הכניסה.
• מה כבר קיים: בדיקות קיימות, במה מריצים אותן, הכיסוי הנוכחי — אילו ענפי לוגיקה נבדקו ואילו לא.
• איך הפרויקט נבנה: פקודת הבנייה, זמן הרצת הבדיקות המלאה, במה מחשבים את הכיסוי.
• מגבלות גישה: האם מותר להוציא קטעי קוד לשירותים חיצוניים או שהיצירה מתבצעת רק בתוך הקונטור שלכם.
• דרישות לבדיקות: אילו תרחישים חובה, והיכן מותר להשתמש באובייקטים מדומים במקום תלויות אמיתיות.
• קריטריון קבלה: איזה שיעור כיסוי ואילו מודולים נחשבים סגורים, ומי מאשר זאת.
• סדר העבודה עם הקוד: לאן מכניסים שינויים, מי עושה ריוויו, והאם נדרשת בדיקה אוטומטית בכל מיזוג.

זה מספיק כדי שנחזור עם הערכה ותכנית עבודה: היקף, שלבים, אזור האחריות בצד שלכם, וסדר ההפעלה של יצירת הבדיקות. תארו את המשימה בצורה חופשית — נדון בפרטים ונציע פורמט להתחלה.