רשומות

תבניות עיצוב ואוטומציה | Template Method Pattern

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

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

מה אנחנו עושים כאשר דבר כזה קורה לנו? לרוב נפנה לדר' גוגל... הרי כל דבר שקרה לנו כבר קרה למישהו אחר בעבר, ובכל בעיה בה נתקלנו, אנחנו כנראה לא הראשונים שנתקלנו בה.
ב-95% מהמקרים גוגל אכן פותר לנו את הבעיה.

מה קורה כאשר אנחנו נתקלים בבעיית Design בקוד שלנו?
אנחנו לא בטוחים כיצד לחבר את ה class-ים או שאנחנו יודעים שמה שעשינו "לא כל כך יפה" אבל אנחנו לא בטוחים כיצד לעשות זאת נכון.

לשם כך נוצרו Design Patterns!
Desing Pattens הן הפתרונות לבעיות שלנו בעיצוב התוכנה - אלו מעין תבניות פתורות וכל מה שנשאר למשתמש זה להתאים אותן למקרה שלו.

במילים אחרות, Design Patterns זה פשוט פתרון לבעיה בעיצוב הקוד.

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

באמצעות template method pattern נוכל לבצע מספר מימושים שונים לאותו שלד של אלגוריתם.

במילים פשוטות…

3 דרכים לייצוב הבדיקות האוטומטיות שלנו

תמונה
כל אחד מאיתנו חווה את זה.
כתבנו test אוטומטי, דיבגנו, הכל עבד מצוין. הרצנו פעם אחת, וזה עבר באופן חלק. אבל מתי שהוא, אולי אחרי כמה פעמים שהרצנו את זה באופן ידני ואולי כשזה רץ באופן אוטומטי בתהליך CI/CD זה או אחר, הבדיקה פתאום נכשלת.
הנושא הזה עייף וגרם לייאוש של עשרות בודקים ומפתחים. למה אותה בדיקה פעם נכשלת ופעם עוברת מבלי כל סיבה הנראת לעין?
הדבר שאנחנו מדברים עליו כאן נקרא Flaky Tests והוא דבר חם מאוד בעולם האוטומציה היום. מה זה Flaky Tests? flaky tests או test flakiness הוא ביטוי המיצג חוסר יציבות של בדיקות אוטומטיות. אם אותה בדיקה, באותם תנאים פעם אחת עברה ופעם אחרי נכשלה, הבדיקה היא flaky.


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

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

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

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

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

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

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


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

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

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

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

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

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

הייתה דממה בקהל. מתוך כ-60 אנשים אף לא יד אחת.

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


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

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

אוטומציה נכונה יותר | שימוש בקבצי קונפיגורציה | קבצי Json

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

על מנת שנוכל להבין יותר טוב את המדריך חשוב להכיר קודם את הנושאים הבאים:

למה חשוב להשתמש בקבצי קונפיגורציה?המבנה של קבצי JsonFactory Design Pattern דוגמה ב C# לשימוש בקבצי Json כקונפיגורציה בדוגמה אציג מקרה עליו כבר דיברנו בעבר - החלטה של הדפדפן עליו ארצה לבצע את בדיקות האוטומציה של המערכת הנבדקת וה-URL של האתר אליו נרצה לגלוש לצורך ביצוע הבדיקות

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


1. התרחיש הראשי שלנו כאשר אני כותב תרחישי אוטומציה (וקוד בכלל) אני אוהב לכתוב את כל הקוד לפי ההתנהגות (Outside-In). זאת אומרת, שקודם כל אכתוב את התרחיש (כאשר הפעולו…

אוטומציה נכונה יותר | שימוש בקבצי קונפיגורציה | C# Settings

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

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

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

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




בתרחיש ניתן לראות שכתובת האתר אליו התרחיש גולש (http://google.com) היא "Hard Coded", זאת אומרת, כתובה ישירות אל תוך הקוד.

מה הבעיה בכתיבה Hard Coded? Hard Coding נחשב ל anti-pattern, לא יעיל ולא פרודקטיבי, והכי חשוב - עלול לגרום לנו ללא מעט בעיות עתידיות.
DRY - כאשר אנחנו כותבים משתנים וקבועים מסוימים אנחנו מסכנים את הקוד שלנו בחילול עיקרון (DRY (Do Not Repeat Yourself, שאומר שאסור לנו לחזור על עצמנו בקוד, בשום פנים ואופן! לא נרצה לכתוב שום שורה פעמיים! העיקרון מעודד אותנו להוציא כל פונקציונליות, פשוטה ככל שתהיה, לפונקציה נפרדת, וכך למנוע כתיבה חוזרת של קוד, ושל משתנים.Maintainability - …

תבניות עיצוב ואוטומציה | Factory Pattern

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

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

מה אנחנו עושים כדבר כזה קורה לנו? לרוב נפנה לדר' גוגל... הרי כל דבר שקרה לנו כבר קרה למישהו אחר בעבר, ובכל בעיה בה נתקלנו, אנחנו כנראה לא הראשונים שנתקלנו בה.
ב-95% מהמקרים גוגל אכן פותר לנו את הבעיה.

מה קורה כאשר אנחנו נתקלים בבעיית Design בקוד שלנו?
אנחנו לא בטוחים כיצד לחבר את ה class-ים או שאנחנו יודעים שמה שעשינו "לא כל כך יפה" אבל אנחנו לא בטוחים כיצד לעשות זאת נכון.

לשם כך נוצרו Design Patterns!
Desing Pattens הן הפתרונות לבעיות שלנו בעיצוב התוכנה - אלו מעין תבניות פתורות וכל מה שנשאר למשתמש זה להתאים אותן למקרה שלו.

במילים אחרות, Design Patterns זה פשוט פתרון לבעיה בעיצוב הקוד.

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


מה זה Factory Pattern? תבנית העיצוב Factory היא אחת מתבניות העיצוב הנפו…