בדיקות לתשתית האוטומציה שלנו | סוגי הבדיקות

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

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

פירמידת הבדיקות - סוגי הבדיקות השונים

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

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

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

הרבדים השונים וחשיבותם

בדיקות יחידה - Unit tests:

בעיני ובעיני רבים, בדיקות היחידה הן החשובות ביותר.

בבדיקות היחידה נרצה לבדוק את היחידה הקטנה ביותר האפשרית לבדיקה - כמו מחלקה או פעולה.

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

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

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

בדיקות קצה לקצה - E2E tests:
החלק שאנחנו, בודקי התוכנה ומפתחי האוטומציה מכירים טוב ביותר.

בבדיקות הקצה לקצה נבצע פעולה שלרוב תדמה פעולת משתמש, אותה פעולה תעבור דרך רכיבים רבים במערכת (לא בהכרח כולם).

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

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

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

כמה להשקיע בכל סוג בדיקות?

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

המספרים נשמעים מטורפים נכון? בכל אופן זוהי ההמלצה של גוגל.
אני חושב ששאיפה פרקטית יותר בהרבה היא 50-30-20.

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

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

איך נוכל לעמוד בפירמידה?

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

ישנו מושג חשוב שנקרא code testability, פירוש המושג הוא - עד כמה הקוד שלנו בדיק.
אם נתייחס למושג הזה בהיבט של Unit Tests, הדבר העיקרי שנצטרך לשים לב אליו הוא SOLID principles.
כלומר, קוד שלא עוקב אחר עקרונות SOLID כנראה אינו ניתן לבדיקה על ידי בדיקות יחידה.

אז על מנת שנוכל להעלות את אחוזי בדיקות היחידה בפירמידה בהחלט הייתי ממליץ על מימוש עקרונות SOLID בקוד שלנו.

דוגמה לכל סוג בדיקות

בואו נבדוק כספומט

Unit Tests:

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

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

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

Integration Tests:

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

חשוב גם לציין כי קיימות בדיקות אינטגרציה שנעשות אל מול הקוד באופן White Box, וקיימות בדיקות שכל אחד יכול לבצע גם ללא היכרות עם הקוד (Black Box).

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

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

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

End to End Tests:

בבדיקות קצה לקצה ננסה ליצור scenario של משתמש.

כאן נכנס לראשו של ה user ונחשוב כיצד הוא הולך להפעיל את התוכנה שלנו.

בדיקות קצה לקצה יכולות להיות מבוצעות מה-API של המערכת שלנו או מה-UI.

בפוסטים הבאים ארחיב על ההבדלים ועל מה עדיף.

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

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

חשוב לזכור!

ככל שהתרחיש שלנו יותר מורכב, מסובך ועובר דרך יותר מחלקות/חבילות/רכיבי תקשורת, כך בתרחיש יהיו יותר נקודות כשל והתרחיש יהיה פחות יציב וקשה יותר לתחזוקה.

סיכום

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

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

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

נתראה בפוסט הבא!