.jpg)
במאמר הקודם דיברנו על הסיבות לבדיקות תשתית האוטומציה שלנו, היום נצלול לעומק הדברים ונדבר על הסוגים השונים של הבדיקות.
לאחר שהגענו להבנה שכדאי לנו לכתוב בדיקות לתשתית האוטומציה שלנו, חשוב שנבין אילו אופציות עומדות בפנינו ובאילו דרכים אנחנו יכולים לבדוק את המוצר שלנו.
פירמידת הבדיקות - סוגי הבדיקות השונים
בעיני, קריטי שכל בודק ומפתח יכיר את הפירמידה הזו ויבין בדיוק את הסיבה לסדר ולחשיבות השלבים בה.
הפירמידה מציגה ארבעה רבדים של בדיקות כאשר על כל אחד ארחיב, כל בדיקה שאנחנו עושים או כותבים נופלת תחת אחד הרבדים הללו.
הרבדים השונים וחשיבותם
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.
במאמרים הבאים ארחיב על ההבדלים ואספק המלצות.
דוגמה לבדיקת קצה לקצה בכספומט: כאשר המשתמש מכניס כרטיס אשראי, עולה מסך של הכנסת סיסמה, במידה והסיסמה שהוכנסה נכונה, יגיע המשתמש למסך של בחירת הסכום למשיכה, לאחר שיבחר סכום כסף למשיכה ובהינתן סכום כזה ביתרתו של המשתמש, יקבל המשתמש את הכסף ואת הכרטיס בחזרה, ויתרתו בחשבון הבנק תעודכן.
על אף שהבדיקה מסמלצת משתמש אמיתי, ניתן לראות כמה מורכבת היא ובכמה רכיבים היא עוברת בדרך לסיום.
!חשוב לזכור
ככל שהתרחיש שלנו יותר מורכב, מסובך ועובר דרך יותר מחלקות/חבילות/רכיבי תקשורת, כך בתרחיש יהיו יותר נקודות כשל והתרחיש יהיה פחות יציב וקשה יותר לתחזוקה
במאמר זה הצגנו את סוגי הבדיקות השונים, דיברנו על חשיבות פירמידת הבדיקות והצגנו דוגמאות לכל סוג בדיקות.
חשוב לציין שזהו רק קצה הקרחון! במאמרים הקרובים אצלול לעומק הדברים ואציג כל סוג בדיקה יותר לעומק. היכרות מעמיקה יותר עם פירמידת הבדיקות תביא לשיפור גדול בידע ובמקצועיות שלנו, הן כבודקים והן כמפתחי תשתיות אוטומציה.
מאת: תומר כהן
Automation team leader
במאמר הקודם דיברנו על הסיבות לבדיקות תשתית האוטומציה שלנו, היום נצלול לעומק הדברים ונדבר על הסוגים השונים של הבדיקות.
לאחר שהגענו להבנה שכדאי לנו לכתוב בדיקות לתשתית האוטומציה שלנו, חשוב שנבין אילו אופציות עומדות בפנינו ובאילו דרכים אנחנו יכולים לבדוק את המוצר שלנו.
פירמידת הבדיקות - סוגי הבדיקות השונים
בעיני, קריטי שכל בודק ומפתח יכיר את הפירמידה הזו ויבין בדיוק את הסיבה לסדר ולחשיבות השלבים בה.
הפירמידה מציגה ארבעה רבדים של בדיקות כאשר על כל אחד ארחיב, כל בדיקה שאנחנו עושים או כותבים נופלת תחת אחד הרבדים הללו.
הרבדים השונים וחשיבותם
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.
במאמרים הבאים ארחיב על ההבדלים ואספק המלצות.
דוגמה לבדיקת קצה לקצה בכספומט: כאשר המשתמש מכניס כרטיס אשראי, עולה מסך של הכנסת סיסמה, במידה והסיסמה שהוכנסה נכונה, יגיע המשתמש למסך של בחירת הסכום למשיכה, לאחר שיבחר סכום כסף למשיכה ובהינתן סכום כזה ביתרתו של המשתמש, יקבל המשתמש את הכסף ואת הכרטיס בחזרה, ויתרתו בחשבון הבנק תעודכן.
על אף שהבדיקה מסמלצת משתמש אמיתי, ניתן לראות כמה מורכבת היא ובכמה רכיבים היא עוברת בדרך לסיום.
!חשוב לזכור
ככל שהתרחיש שלנו יותר מורכב, מסובך ועובר דרך יותר מחלקות/חבילות/רכיבי תקשורת, כך בתרחיש יהיו יותר נקודות כשל והתרחיש יהיה פחות יציב וקשה יותר לתחזוקה
במאמר זה הצגנו את סוגי הבדיקות השונים, דיברנו על חשיבות פירמידת הבדיקות והצגנו דוגמאות לכל סוג בדיקות.
חשוב לציין שזהו רק קצה הקרחון! במאמרים הקרובים אצלול לעומק הדברים ואציג כל סוג בדיקה יותר לעומק. היכרות מעמיקה יותר עם פירמידת הבדיקות תביא לשיפור גדול בידע ובמקצועיות שלנו, הן כבודקים והן כמפתחי תשתיות אוטומציה.
מאת: תומר כהן
Automation team leader
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר