רווחים:
- יכולת למנוע מבינה מלאכותית לקבל התנהגות שגויה כ'נכונה' על ידי חישוב הערך הצפוי במבחני יחידה ללא תלות בכלל הקבלה
- יכולת להדפיס בדיקות מהירות, עצמאיות וניתנות לשחזור על ידי יישום עקרונות AAA ו-FIRST ולעג לתלות חיצונית
- יכולת בדיקת בדיקות עם מוטציה (שבירת קוד) וזיהוי קוד קשה לבדיקה כריח עיצובי
השכבה הגדולה והמהירה ביותר של פירמידת הבדיקה היא בדיקת יחידות - בדיקה המאמתת פונקציה או פיסת קוד קטנה במנותק מכל השאר. אלפי בדיקות יחידות רצות תוך שניות ותופסות באג בזמן שהקוד עדיין על מסך המפתח. בינה מלאכותית (AI) היא אולי הבקיאה ביותר בייצור בדיקות יחידה: אתה נותן לה פונקציה, AI מייצר עשרות בדיקות. אבל עצם הנוחות הזו מולידה את המלכודת הגדולה ביותר: בינה מלאכותית מייצרת בקלות בדיקות ש"זוהרות בירוק אבל לא מאמתות כלום" או מקבלים את ההתנהגות הנוכחית (אולי השגויה) של הקוד כ"נכונה". ביחידה זו תלמדו כיצד לכתוב בדיקות יחידות מגן באמת עם AI ואת הקשר בין קוד שניתן לבדיקה ובינה מלאכותית.
תכונות של מבחן יחידה טוב: FIRST
מבחני יחידה טובים פועלים לפי עקרונות ראשונים: מהיר, עצמאי (מבחנים לא צריכים להיות תלויים זה בזה), ניתנים לחזרה (ניתנת לחזרה - אותה תוצאה בכל סביבה), תוקף עצמי (ברור עובר/נכשל), בזמן (בזמן). הזכירו לעצמכם את העקרונות האלה כאשר AI מייצר בדיקות; בקשו ספציפית שהבדיקה לא תהיה תלויה בעולם החיצון (מסד נתונים בפועל, רשת, שעון) להיות "בלתי תלויה" ו"ניתנת לחזרה".
דפוס AAA וטענה אקספרסיבית
מבחן יחידה מוצק עוקב אחר מבנה ה-AAA: ארגן (הכן - הגדר תשומות ותלות), פעל (ביצוע - קרא לפונקציה הנבדקת), Assert (אמת - השווה את התוצאה עם הערך הצפוי). הקריטי הוא טענה. הטעות הנפוצה ביותר שעושה AI היא גזירת הטענה מהפלט של הקוד הנבדק - ההיגיון "כל מה שהקוד מחזיר הוא נכון". זה הופך את המבחן לחסר משמעות. הדרך הנכונה היא לקבוע את הערך הצפוי באופן עצמאי (מקריטריוני הקבלה, לחשב אותו באופן ידני).
שים לב: אם אתה אומר ל-AI "כתוב מבחן עבור פונקציה זו", ה-AI עשוי להפעיל את הפונקציה ולכתוב את הפלט שלה כ"צפוי". בדיקה זו עוברת גם אם הפונקציה היא שקר. במקום זאת, אמור "אתה מחשב את התוצאות הצפויות לפי כללים אלה, אל תתייחס לפלט הנוכחי של הפונקציה."
לעג, בדל ותלות
בדיקת יחידה דורשת בידוד. אם הפונקציה שלך תלויה במסד נתונים או ב-API, הם מוחלפים באובייקטים מדומים (דמה/סטאב - תחליף מבוקר דמה לתלות האמיתית) בבדיקה. זה הופך את הבדיקה למהירה, עצמאית וניתנת לשחזור. AI יכול לייצר התקנה מדומה; אבל היזהרו מלעג מוגזם: אם לועגים לכל דבר, הבדיקה תוודא רק "מה הלעג מחזיר", לא את ההיגיון בפועל. איזון: לחקות את העולם החיצון, לבצע את ההיגיון האמיתי הנבדק.
יכולת בדיקה ובינה מלאכותית
יש משוב מעניין: קוד שקשה לבדוק הוא לעתים קרובות קוד מעוצב בצורה גרועה. אם ה-AI מתקשה לכתוב מבחנים לפונקציה (יותר מדי תלות, מצב גלובלי נסתר, תופעות לוואי), זה ריח עיצובי. השאלה של הבינה המלאכותית "איך היית משנה את הקוד הזה כדי שיהיה ניתן לבדיקה" מובילה גם לבדיקות טובות יותר וגם לקוד טוב יותר.
בדיקות פרמטריות וגיוון נתונים
כתיבת מבחן נפרד בכל פעם כדי לאמת את אותו כלל עם תשומות שונות היא מייגעת וקשה לתחזוקה. בדיקות פרמטריות - מבנה שמריץ שוב ושוב את אותה לוגיקית בדיקה ברשימת קלט ותוצאות צפויות - מבטלת את החזרה הזו: גוף בדיקה בודד מוזן בעשרות זוגות קלט. בינה מלאכותית יעילה מאוד בהפקת טבלאות התוצאות הצפויות לקלט כאשר אתה נותן לה את כללי הקבלה שלך; בפרט, הוא מציג טבלאות שיטתיות של ערכי גבול ושיעורי שוויון.
אבל גם כאן יש מלכודת: ה-AI נוטה לגזור את התוצאות הצפויות בטבלה שנוצרה מהקוד הנבדק. שגיאה זו מסוכנת אף יותר בבדיקות פרמטריות, מכיוון שהיגיון שגוי יחיד מבטל עשרות שורות. לכן, תמיד חשב את עמודת התוצאה הצפויה באופן עצמאי לפי כלל הקבלה ואמת ידנית לפחות כמה שורות. בקש גם עמודת תיאור "מה מייצגת כל שורה"; כך שכאשר שורה נשברת אתה רואה מיד איזה מצב מקולקל.
טיפ: הוסף בכוונה "שורת מלכודת" לטבלת הבדיקות עם הפרמטרים - כלומר, הקלד שגוי ביודעין את התוצאה. אם הקו הזה לא הופך לאדום כשאתה מפעיל את הבדיקה, הבדיקה שלך לא באמת מאמתת את המצב הזה. זוהי בדיקה מדומה מהירה.
הנחיה חלשה / הנחיה חזקה
חלש: "כתוב מבחן יחידה עבור הפונקציה הזו."
חזק: כתוב בדיקות יחידה [שפה/מסגרת] עבור הפונקציה "TaxCalculate(amount, rate). כלל קבלה: תוצאה = סכום * שיעור, מעוגל ל-2 עשרונים; סכום שלילי או שיעור זורקים שגיאה; מחזיר 0 אם שיעור הוא 0. השתמש במבנה AAA. חשב באופן ידני את הערכים הצפויים בהתאם לכללי הפלט הנוכחיים של הפונקציה האלה, ואל תתייחס למקרים שליליים, גדולים מאוד, שליליים, 0. עיגול לעשרונים). תנו לשם של כל מבחן לתאר את הכלל שהוא מאמת את התלות החיצונית "לא".
הנחיה עוצמתית; זה נותן את כלל הקבלה, תוחלת ערך צפוי עצמאי, מבנה ומקרי קצה. לפיכך, המבחן הופך לאפוטרופוס של הכלל, לא למראה של הקוד.
טבלת איכות בדיקת יחידה
סימפטום
מבחן גרוע (אמון מזויף)
מבחן טוב
לטעון
ללא או "לא ריק"
ערך קונקרטי צפוי
מקור ערך צפוי
פלט של הפונקציה
כלל קבלה / חישוב ידני
התמכרות
DB/רשת/שעה בפועל
מבודד עם מדומה/בדל
מארז קצה
רק דרך שמחה
גבול, שלילי, שגיאה
כשאתה שובר את הקוד
נשאר ירוק
הופך לאדום
שם
test1, testMethod
מתאר את הכלל שהוא מאשר
ארבע תבניות הניתנות להעתקה
1) בדיקת יחידה מונעת על ידי כללים:
תפקידך: מהנדס בדיקות תוכנה בכיר. כתוב מבחן יחידה על הפונקציה הבאה עם [שפה/מסגרת]: [חתימה]. כללי קבלה: [כללים].- השתמש במבנה AAA.- חשב באופן ידני את הערכים הצפויים לפי הכללים האלה; אין להתייחס לפלט הנוכחי של הפונקציה. - כסה את הגבול, השלילי, השגיאה והנתיב המאושר עם בדיקות נפרדות. - תן לכל שם בדיקה לתאר את הכלל שהוא מאמת. - לעג לתלות חיצונית; תגרום להיגיון בפועל לעבוד.
2) בקרת התנגדות למוטציות:
בדוק את בדיקות היחידה הללו. רשום 5 שינויים קטנים שאוכל לבצע בקוד הנבדק (a - במקום +, a >= במקום >, שינוי גבול) ותגיד לי לגבי כל אחד מהם מהבדיקות האלו יהפוך לאדום? אם לא הוחזרו, הבדיקה אינה מספקת. קוד + בדיקות: [הדבק]
3) סקירת יכולת בדיקה:
מדוע קשה לכתוב מבחן יחידה עבור פונקציה זו? התמכרות נסתרת, מעמד גלובלי, תופעות לוואי, האם יש הרבה אחריות? הצע ריפקטור מינימלי כדי שיהיה ניתן לבדיקה; לא לשנות התנהגות. קוד: [הדבק]
4) השלמת תרחיש לא מלאה:
הפונקציה הבאה והבדיקות הזמינות ניתנות. רשום איזה התנהגות/מקרה קצה מעולם לא נבדק (פער היקף) והוסף מבחן לכל אחד מהם. פונקציה+בדיקות: [הדבק]
שלושה מיני תיקים
מקרה 1 - בדיקה בשיקוף הקוד. מפתח ביקש מה-AI לכתוב מבחן לפונקציית העיגול; 10 מבחנים היו ירוקים. למעשה, הפונקציה התעגלה בכיוון הלא נכון, אבל ה-AI לקח את הערכים הצפויים מהפלט של הפונקציה, כך שהבדיקות ראו את השגיאה "נכונה". כאשר הערכים הצפויים חושבו באופן ידני עם התבנית "מנוהלת כללים", 4 בדיקות הפכו לאדומות והשגיאה האמיתית התגלתה.
מקרה 2 - הערך של בקרת מוטציות. צוות אחד הסתמך על 45 בדיקות יחידות. ניסיתי 20 שינויים קטנים בקוד עם "בדיקת חוסן מוטציה"; מבחנים תפסו רק 11 מהם. 9 השיבושים הנותרים עברו בשקט. הצוות חיזק מבחנים חלשים; שגיאת חישוב ממשית נתפסה על ידי בדיקות משופרות אלה במהדורה הבאה.
מקרה 3 - חוסר בדיקה הוא ריח עיצובי. הבינה המלאכותית לא יכלה לכתוב בדיקות לפונקציית הזמנה, היא נזקקה כל הזמן למסד הנתונים האמיתי. תבנית "סקירת הבדיקה" הראתה שהפונקציה הטביעה גישה למסד נתונים. כאשר הוסרה הזרקת התלות, ניתן היה לכתוב בדיקות והקוד נעשה נקי יותר.
טעויות נפוצות
- גזירת הערך הצפוי מקוד. ה-AI מקבל את פלט הפונקציה כ"נכון"; בדיקה שמאשרת קוד פגום.
- מבחן ללא טענה או עם טענה טריוויאלית. היגיון "הוא לא זרק שגיאה, הוא עבר"; זה לא מאשר כלום.
- לעג קיצוני. לועגים לכל דבר ובודקים רק מה הלעג מחזיר; ההיגיון האמיתי לא נבדק.
- רק הדרך המאושרת. עקיפת מגבלה, מצבי שלילי ושגיאה.
- לא בודק על ידי שבירת הקוד. סומך על ירוק מבלי לבדוק מוטציה.
- התעלמות מחוסר בדיקה. לא לזהות ולתקן עיצוב גרוע במקום לדחוף בדיקות קשות.
לסיכום
בדיקות יחידות הן השכבה המהירה והגדולה ביותר של פירמידת הבדיקה; הוא תופס את הטעות ברגע הזול ביותר. בינה מלאכותית מסוגלת מאוד לייצר בדיקות יחידה, אבל המלכודת הגדולה ביותר שלה היא כתיבת בדיקות המניחות התנהגות שגויה כ"נכונה" על ידי גזירת הערך הצפוי מהקוד עצמו. פתרון: תן את כללי הקבלה, חשב את הערכים הצפויים באופן ידני, אכף את עקרונות AAA ו-FIRST, לועג לעולם החיצון והפעל את ההיגיון בפועל, ובדוק כל בדיקה על ידי מוטציה (שבירת הקוד). קוד שקשה לבדוק הוא סימן עיצובי שצריך לתקן.
משימת יישום
בחר פונקציה המכילה כלל עסקי מהפרויקט שלך. כתוב כללי קבלה וקבל את מבחני כתיבת הבינה המלאכותית עם התבנית "בדיקת יחידה מונעת על ידי כללים"; יש לחשב את הערכים הצפויים באופן ידני. לאחר מכן החל את "בדיקת חוסן המוטציה": בצע לפחות 5 הפסקות קטנות בקוד ומדוד כמה בדיקות הופכות לאדומות. הוסף מבחן חדש לשחיתויות שלא נתפסו. דווח כמה שיבושים נתפסו (כגון ציון מוטציה).
רשימת בדיקה
- [ ] נתתי את כללי הקבלה וחישבתי באופן ידני את הערכים הצפויים.
- [ ] וידאתי שהבדיקות לא גוזרות את הערך הצפוי מהקוד.
- [ ] הקמתי בדיקות עצמאיות בהתאם להנחיות AAA ו-FIRST.
- [ ] לעגתי לתלות החיצונית והרצתי את ההיגיון בפועל.
- [ ] כיסיתי במקרים של הגבלה, שלילי ושגיאה.
- [ ] על ידי שבירת הקוד (מוטציה) הוכחתי שהבדיקות אכן מגנות.