רשומות

עיצוב תוכנה - Top-down programming

תמונה
בפוסט של היום אני רוצה לדבר על קונספט שישמע תחילה בסיסי ומובן מאליו, אבל לאורך הקריאה אני ממליץ מאוד לשאול את עצמינו בשיא הביקורתיות - האם כך אני באמת כותב קוד? ואם לא, אולי כדאי לי להתחיל?
כולנו יודעים שרוב התוכנות, המערכות, ואפילו הסקריפטים שאנחנו כותבים לא מסתכמים בפונקצייה אחת ולא בשתיים. ככל שתוכנה שאנחנו כותבים מורכבת יותר וככל שאנחנו נרצה להפוך את הקוד שלנו לקריא יותר וגנרי יותר כנראה יהיו בו יותר קלאסים ופונקציות.
במקום לדבר הרבה ולנסות להסביר את המונח באופן אבסטרקטי, פשוט אצלול לדוגמה (top-down לא?).
דמיינו שאתם עובדים בצוות בו עובדים עם מכונות וירטואליות על גבי vcenter (פלטפורמת ניהול vms של vmware) והאוטומציה שרצה מייצרת הרבה מכונות. את המכונות הללו אנחנו רוצים לנקות בסוף כל יום עבודה כדי לא לצבור עומס מיותר, בהנחה שאם מישהו יצטרך את אחת המכונות הוא פשוט יזיז אותם לתיקייה אחרת.

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

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

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

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

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

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

Allure Reporter - הטמעת דוחות ריצה באוטומציה

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

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

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

Stop using time.sleep everywhere!

תמונה
I think that almost every automation infrastructure that I have seen has the time.sleep() method at least once.
Sometimes it comes from laziness and sometimes from a lack of knowledge, but I believe that in at least 90% of the times, sleep methods should not appear in our code. Why do we need the sleep method at all? In the e2e automation world, when we try to automate the AUT (application under test), we sometimes depend on processes we do not control. For example, as automation developers, when we click on a button to switch pages in the AUT, we don't have control on the pace that the new page is loaded, it depends on many variables like the network speed and communication with third party systems (like databases and servers).
When the automation developer starts an operation that can take time (like the page loading in the example) and continues his test flow right after, the test may fail due to missing information of the application. for example, if we try to click on button…

תבניות עיצוב ואוטומציה | 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, קריאה למחלקות נוספות וכ…