ה-Galen הינו עוד אחד מאותם הפריימווריקם החביבים האלו, שקל להתקין, קל להבין , קל לעבוד וקל לאהוב אותם. הוא נותן לנו פתרון אלגנטי עם גישה מעט שונה לאחת מהבעיות הקשות בתחום בדיקות התוכנה האוטומטיות – בדיקות הויזואליזציה (Visual Testing).
מהן בדיקות ויזואליזציה ?
בבדיקות אלו אנו מוודאים כי האפליקציה שלנו נראית כפי שהיא אמורה להיראות מבחינת הממשק הגרפי שלה, מה הכוונה ? שאותו אתר לצורך הדוגמא, נראה כפי שהיינו מצפים ממנו להיראות על מסך של סמארטפון, מסך של טאבלט, מסך של לפטופ ומסך של 4K…
אילו כלי אוטומציה עומדים לרשותינו כיום בבואנו לבדוק ויזואלית את האפליקציה ?
* Sikuli – אולי הכלי המוכר ביותר בשוק, כלי Open Source, פרי פיתוח של מעבדות MIT .
* Applitools – פרי פיתוח של חברת Applitools הישראלית, ללא ספק הכלי הטוב ביותר פה ברשימה, אך הוא גם הכלי המסחרי היחיד כאן ברשימה
* PhantomCSS – עובד עם JS, החל מסוף שנת 2017 הפסיק כבר להתעדכן
* Needle – עובד עם Python
* FBSnapshotTestCase – עובד על Mobile – iOS
* Selenium Visual Diff – עובד עם Java
* Vizregress – עובד עם NET.
המשותף לכל הכלים הללו שהם עובדים בגישה של השוואת תמונות.
לכולם יש מנוע השוואת תמונות, מי יותר ומי פחות טוב, כאשר המנוע משווה פיקסל לפיקסל בין התמונה המוצגת על המסך כעת (Actual Result) לבין תמונה אחרת שדאגנו לצלם לפני כן (Expected Result או BaseLine).
לבדיקות המסתמכות על השוואה של תמונות יש יתרונות וחסרונות. אחד הדברים הכואבים לנו – מפתחי האוטומציה הוא התחזוקה של הפרוייקט שלנו ורוב שעות האדם שאנו משקיעים בפרוייקט אוטומציה קשורות לתחזוקה. במקרה הזה, כשעובדים מול תמונות – התחזוקה יקרה פי כמה וכמה מאשר אם אנו עובדים על ה-DOM למשל.
ניקח לדוגמא מקרה בו לקחנו 200 צילומי מסך (הן יהיו ה-expected result שלנו) של האפליקציה בגרסה 1.0 , עברו חודשיים וגרסה 2.0 יצאה לאויר, אחד מהפיצ'רים של גירסה זו היה שינוי ה-GUI של האפליקציה, מה זה אומר עלינו בבדיקות ? זה אומר שאנו נצטרך לקחת שוב את ה-200 התמונות המעודכנות ולהפוך אותן ל-expected result. זה המון עבודה. צריך לקחת בחשבון שיש לקחת אפילו יותר תמונות במידה ונרצה גם לתמוך בדפדפנים שונים (תצוגה באינטרנט אקספלורר לעיתים שונה מאשר גוגל כרום) וכמובן בניידים שונים.
Applittols אגב פתרו באופן אלגנטי את עניין התחזוקה עם פיצ'רים משלהם כך שניתן לתחזק את 200 צילומי המסך בלחיצת כפתור אחת…
להלן דוגמא לאופן העבודה של image based visual testing tools:
ראוי לציין כי בנוסף לעניין התחזוקה הבעייתי ברוב כלי ה-Image Based, יש גם את עניין ה-Performance , השוואה של תמונות פיקסל לפיקסל גוזל זמן רב וכן צריך לקחת בחשבון שישנם כלים שמנוע השוואת התמונות שלהם הוא לא מספיק חזק, דברים אלו באים לידי ביטויי ברזולוציות נמוכות.
ה-Galen Framework שנכתב על ידי מפתח בשם: איגור שובין, גם מיועד לשוק בדיקות הויזואליזציה, אלא שבניגוד לקודמים, הוא אינו מתבסס על השוואה של תמונה, אלא על השוואת האלמנטים ב-DOM, או יותר נכון – על ה-Style של האלמנטים אחרי שאלו מרונדרים (Rendered) ע"י הדפדפן. במילים אחרות, ה-Galen Framework יודע לעבד את ה-CSS של העמוד ולעבוד לפיו.
זהו מוצר שחי בקהילת הקוד הפתוח כבר כמה שנים טובות, מתוחזק כהלכה ומכיל המון פיצ'רים בתוכו. הוא רוכב מעל ספריות הקוד של סלניום ושואב משם את המידע הרלוונטי.
ה-Galen כולל בתוכו כמה פי'צרים מרכזיים:
1. קובץ Spec עשיר הכתוב בשפה אנושית כך שאנשי בדיקות ללא רקע בקוד יוכלו לכתוב טסטים בצורה מהירה
2. מערכת דוחות מתקדמת מעל דפי ה-HTML
3. צילומי מסך חכמים המכילים בתוכם גם Data נוסף
4. מנוע השוואת תמונות. כן כן, למרות שהכלי הזה לא התחיל כך, בשלב מסויים החליט המפתח לתמוך גם בזה וליישר קו (ואף לעקוף) את שאר הכלים האחרים
5. כאמור, הוא עובד מעל ספריות הקוד של סלניום, על כן ניתן לבצע איתו גם בדיקות פונקציונליות
בואו נראה איך הכל עובד, אך לפני כן, נגדיר דף עליו נרצה לבצע את הבדיקה. הדף שבחרתי הינו הקורס של PostMan לבדיקות API אצלי באתר.
חילקתי את הדף לכמה איזורים (אלמנטים) אותם אני רוצה לבדוק, גם בדיקות של מימדים, גם בדיקות עימוד נכון וגם בדיקות צבעים ותמונות, ניתן לראות את החלוקה כאן:
קובץ ה-Spec אם כך יכלול את האלמנטים המופיעים בדף, ייצוג האלמנטים אינו שונה מאותו ייצוג המוגדר ב-Selenium WebDriver (הסינטקס מעט שונה):
שימו לב שהגדרתי פה 7 אובייקטים (אלמנטים) על פי הלוקייטורים המוכרים לנו כבר מסלניום: id (שמיוצג על ידי #) , className (שמיוצג ע"י .) ו-xpath (אבסולוטי ורלטיבי)
בדיקה אחת יכולה לבדוק את מימדי האלמנט courseAdv , שזוהי הפירסומת לקורס האוטומציה שמופיעה מצד ימין למטה:
ואני יכול להמשיך עם הבדיקות האחרות על אותו אלמנט, כך למשל:
מה אנחנו רואים כאן? למעשה ה-Spec מדבר בעד עצמו, גם מבלי שאסביר, באופן די אינטואטיבי, רק על פי השמות נוכל לדעת מה בדיוק אנחנו בודקים.
למשל, בשורה 15, אנחנו בודקים שה-courseAdv ממוקם מצד ימין ל-mainArea והמרווח ביניהם הוא 31 פיקסלים בדיוק.
אנחנו גם בודקים כאן (שורה 16) שה-courseAdv ממוקם מתחת ל-agendaArea בין 28 לבין 32 פיקסלים, זאת אומרת שאני לא חייב לתת מספר אבסולוטי, אלא טווח.
בשורה 18 אנחנו בודקים שה-courseAdv ממוקם בתוך האלמנט mainCont כאשר הוא ממוקם 476 פיקסלים מהחלק העליון ו-15 פיקסלים מצד ימין
בדיקה נוספת שניתן לעשות עם Galen מבוססת על צבעי האלמנטים, כך למשל:
אני בודק שהכותרת של "פרקי הקורס" היא בערך 10 אחוז לבן ומעל 50 אחוזים צבע תכלת-טורקיז (אותו מייצג הערך ההקסדצימלי אחרי הסולמית), במילים אחרות, אני בודק את הצבעים של האלמנט הזה:
אגב, את ה"בערך" שמיוצג על ידי התילדה, אנו קובעים במסמך Config של Galen , ערך ברירת המחדל שלו הוא 2 , זה אומר שבמקרה הזה, הצבע הלבן יכול לנוע בין 8 אחוזים לבין 12 אחוזים.
וכמובטח, עם Galen ניתן גם להשוות תמונות כך:
כאן אנו מגדירים תמונה ששמרנו מבעוד מועד (קוראים לה: video_postman1.png) ומשווים אותה לתמונה שהוא לוקח בזמן הריצה, עם אפשרות לשוני בין 2 התמונות עד 2 אחוזים.
ההרצה של הבדיקה מתבצעת דרך ה-Command Line עם פקודת ה-check ושליחת פרמטרים, כך למשל:
אחרי שהטסט רץ, אנו נראה את דוח הריצה גם בקונסול, כך למשל:
ובמקרה של כישלון, נראה כך (שיניתי את הרוחב והגובה של האלמנט):
ה-Galen כאמור תומך גם ב-Report על בסיס HTML , שימו לב כי בשליחת הפרמטרים, הכנסנו לו גם שם ספרייה היכן לשמור את ה-Report, כשנפתח אותה נקבל את קבצי ה-report (קבצי HTML, JS, CSS, JSON ועוד).
כך נראה מקרה של הצלחה:
וכך של כישלון:
* ב-Report ה-HTML-לי ניתן ללחוץ על כל אלמנט והוא יציג צילום של המסך בזמן הריצה תוך כדי הדגשה על האלמנט הספציפי
אבל רגע, זה לא הכל….
עשינו את הבדיקה רק על קליינט אחד ? אנחנו גם נרצה לבדוק את אותו אתר שמופיע על סמארטפון, נכון ? איך עושים את זה ? האם נכתוב מסמך Spec חדש לסמארטפון ? האם נכתוב מסמך חדש לטאבלט ? או לפאבלט ? זה יהיה קצת טיפשי לעבוד בצורה כזו. אז ב-Galen חשבו על כך ונתנו לנו את האפשרות להגדיר את כל סוגיי הקליינטים עם הרזולוציות שלהם באותו מסמך ועשו זאת גם בצורה חכמה.
לשם כך אנחנו צריכים להכיר קובץ נוסף ש-Galen תומך בו (מלבד ה-spec) והוא נקרא test. אם האחריות של ה-spec הינה לבדוק דף HTML ספציפי, האחריות של ה-test הוא ליצור מקרה בדיקה, תוך ניווט בין דפים שונים ופעולות על אלמנטים (רוכב מעל הספריות של סלניום, זוכרים ?)
כך יראה קובץ ה-test שלנו לבדיקה על 2 קליינטים, האחד עם רזולוציה של: 480×800 והשני עם רזולוציה של: 1920×1080
שימו לב כמה פונקציונליות נתמכת בקובץ ה-Spec בשביל לחסוך לנו שורות קוד מיותרות , יש לנו איזור של הגדרות שמשרת את כל המסמך (set@@) , אנחנו מגדירים את הקליינטים שלנו אל טבלה של מכשירים (table devices@@), ויש לנו גם אופציה לשלוח את הערכים מתוך הטבלה כפרמטרים לבדיקה, ה-parameterized using devices@@ יודע לרוץ בלולאה על כל איברי הטבלה ולבצע עליהם את הבדיקה שקיימת תחת מסמך ה-postman.gspec
כתבתי בתחילת הפוסט כי ניתן גם לבצע פעולות אוטומטיות על הדפדפן ולא רק visual testing, אפשר לעשות זאת בשני אופנים:
1. ליצור קובץ JS ולהכניס לשם פקודות JavaScript שירוצו ישירות מעל הדפדפן
2. ליצור קובץ JS ולהכניס לשם פקודות Selenium WebDriver
דוגמא לפקודת JavaScript:
document.getElementById("postman").click();
כאשר הקריאה לקובץ זה במסמך ה-test תהיה:
דוגמא לפקודות Selenium:
var userName = arg.name;
var userEmail = arg.email;
driver.findElement(By.cssSelector("a[href='video.html']")).click();
driver.findElement(By.id("postman")).click();
driver.findElement(By.id("name")).sendKeys(userName);
driver.findElement(By.id("email")).sendKeys(userEmail);
כאשר הקריאה לקובץ זה במסמך ה-test תהיה:
שימו לב שאנחנו יכולים גם לשלוח פרמטרים מבחוץ לקובץ ה-JS
מכיוון שכבר הכנסנו את כל הפרמטרים אל תוך קובץ ה-test, כשנרצה להריץ מה-Command line נצטרך רק לקרוא לטסט עצמו עם ספריית ה-reports:
וה-Report יראה כך:
ישנם פיצ'רים נוספים ב-Galen, אותם לא הראיתי כאן, כמו הרצה עם Selenium Grid ועבודה מול דפדפנים שונים או עבודה עם Page Objects, החסרון המרכזי שמצאתי ב-Galen הוא שלא ניתן לשלב אותו בתוך פרוייקט קיים אלא כפרוייקט נפרד וזה סתם מרגיז כי זה אומר שעלינו לתחזק כעת 2 פרוייקטים. מקווה שבעתיד תישקל האופציה להכניס את הספריות הקוד לפרוייקט בג'אווה \ סי שארפ או אחרים כך שנוכל לעבוד בצורה נוחה יותר.
מילה טובה גם על מערך הדוקומנטציה המצויין שקיים באתר שלהם, קשה ללכת שם לאיבוד, הן בגלל שזהו פריימוורק קליל והן בגלל שהם דואגים לידע אותך על כל פיצ'ר.