יצירת בדיקות יחידה באמצעות בינה מלאכותית: הגדרת צינור ואינטגרציות

למה יצירת בדיקות ב-AI לא מצילה את הכיסוי בעצמה

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

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

כעבור חודש הצוות מפסיק לקרוא את הדוח ומריץ 'ליתר ביטחון' — האמון בתוצאה יורד מהר יותר ממספר הבדיקות.

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

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

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

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

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

השוואת מצבים: לפי שינויים, לפי חיתוך, לפי לוח זמנים

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

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

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

שלבי ההטמעה: ביקורת, סכימה, הגדרה, בדיקה

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

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

1. ביקורת מערך הבדיקות. מפרקים את הכיסוי לפי מודולים, מסמנים כפילויות ובדיקות מתות, מתעדים את זמן הריצה ואת שיעור הבדיקות הלא יציבות כנקודת ייחוס.
2. סכימת אינטגרציה לבנייה. קובעים היכן משתלבת היצירה: כשלב נפרד בצינור, לפי שינוי קבצים או לפי לוח זמנים, וכיצד התוצאה מגיעה לענף המשותף.
3. הגדרת כללי הרצה. מגדירים תיקיות נראות וחריגים, דרישות לבדיקה: ערכי גבול, חריגים צפויים, בידוד פניות לרשת ולשירותים חיצוניים.
4. בדיקה על מודול אחד. מריצים את המעגל על קטע מוגבל, משווים את התוצאה לבדיקות שנכתבו ידנית, מסננים וריאנטים שעוברים בכל לוגיקה.
5. קבלת התוצאה. מחשבים את שיעור הבדיקות שעברו, את הגידול בהסתעפויות המכוסות ואת זמן הריצה; בדיקות שאינן תופסות החלפת לוגיקה מוסרות מהמערך.
6. העברת המעגל לצוות. מוסרים קונפיגורציות, כללי הרצה והוראות כיצד לשנות דרישות ולחבר מודולים חדשים בלעדינו.

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

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

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

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

מקרה בוחן: כיצד גדל הכיסוי ומה קרה עם הרגרסיה

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

מה שינו בצינור

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

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

מה קרה למדדים

שיעור הכיסוי עלה מ-41% ל-76%, בשורות שהשתנו הוא נשמר מעל 90%. בדיקת שינויים התקצרה מ-40 ל-12 דקות, סקירת בדיקות אורכת 3-4 דקות במקום כתיבה מאפס. פגמים שהוחמצו ברבעון — שניים במקום תשעה, ושניהם בממשקי אינטגרציה שבהם היצירה לא יושמה בכוונה.

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

ספקות טכניים לפני תחילת העבודה

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

האם לא נקבל מאה בדיקות כפולות?

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

מה יקרה בעת שינוי קוד וריפקטורינג?

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

כיצד בודקים שהבדיקה אינה ריקה?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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

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

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

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

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

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

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