When Not to Use Cucumber
לא תמיד צריך מלפפון בסלט

איתי אגמון, CTO מטריקס טופ קיו

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

 

אז מה זה בעצם Cucumber?

Cucumber מבוסס על רעיונות שפותחו ע"י דן נורס בשנת 2006. נורס מספר שחיפש דרך ללמד מפתחים לכתוב בדיקות יחידה (Unit Tests) בסביבת Agile והתקשה לטוות להם דרך פשוטה שתסייע להם לדעת מה לבדוק, מה לא לבדוק וכמה לבדוק בכל בדיקה בודדת. כתוצאה מכך נורס פיתח גישה חדשה בשם "פיתוח מונחה התנהגות" (BDD). בגישה זו, אנו מגדירים את הבדיקות שלנו באמצעות משפטים בשפת מדוברת. נפוץ לכתוב אותם באנגלית אבל אפשר בעצם כמעט בכל שפה, אפילו בעברית, רק שאותם משפטים חייבים לעמוד בחוקיות מסוימת. המשפטים הראשונים מתחילים ב"בהינתן" (Given) ומתארים את המצב בו צריכה להיות המערכת הנבדקת כדי שנוכל לבצע עליה את הבדיקה. לאחר מכן, מגיעים משפט או מספר משפטים שמתחילים ב"כאשר" (When) ומתארים את הפעולה אותה אנו רוצים לבצע על המערכת ולבסוף משפטים שמתחילים ב"אז" (Then) ומתארים את הפעולה או הפעולות הנדרשות כדי לבדוק שהמצב שנוצר, כתוצאה מהבדיקה שעשינו, הוא אכן המצב לו ציפינו.

 

בואו נראה דוגמה:

בהינתן ומסך הטלוויזיה דלוק

כאשר אני לוחץ על מקש הכיבוי

אז מסך הטלוויזיה נכבה

 

מבנה המשפטים הזה נקרא Gherkin וכך בעצם נכתבים המבדקים ב-Cucumber (ובמגוון כלים נוספים המבוססים על גישת BDD). כל משפט שנכתב בעצם ממופה לפונקציה בשפת קוד שמבצעת את ההוראות הנדרשות על המערכת הנבדקת.

 

אז מה קיבלנו פה בעצם?

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

 

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

 

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

 

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

 

מי שמעוניין בכלים המאפשרים לכתוב מבדקים ללא ידע בקידוד, יכול לעשות שימוש במערכות אחרות ממשפחת ה-(Keyword Driven Testing (KDT. מערכות אלו, כמו Robot Framework או Gauge, תוכננו למטרה זו ולמרות הדמיון ביניהם לבין מערכות מסוג BDD, הן מתאימות הרבה יותר לשילוב אנשי ה-QA בתהליך האוטומציה. מערכות אלו מאפשרות לייצר מילים, שבפועל, דומות יותר ממשפטי Gherkin לפונקציות של שפות פיתוח סטנדרטיות ובכך מצליחים לאפשר יכולות רבות שמתאימות הרבה יותר ליצירה של תשתיות אוטומציה גמישות וניתנות לשימוש חוזר.

 

אז למי כן מתאים להשתמש ב-Cucumber?

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

 

כותב המאמר הינו איתי אגמון, CTO ב-Top-Q.
מעוניינים לשמוע עוד מאיתי? צרו קשר


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

רוצים לשמוע עוד? דברו איתנו

מלאו פרטים ונחזור אליכם בהקדם