תומרקוד

פעמים רבות בתרחישי אוטומציה ובמערכות בכלל, אנו נדרשים להשתמש במשתנים או בקבועים כמו נתיבים לקבצים, שמות של קבצים, פורטים, כתובות של אתרים וכו'.. היום נדבר על החשיבות של קבצי קונפיגורציה בתשתית האוטומציה שלנו. לפני שנצלול לעומק הדברים אני רוצה לתת דוגמה לקוד שאני רואה לא מעט. הקוד מתייחס למדריך שעשיתי בעבר על כתיבת תרחישי אוטומציה באמצעות Selenium נסה להסתכל על הקוד ולחשוב מה הבעיה כאן... בתרחיש ניתן לראות שכתובת האתר אליו התרחיש גולש (http://google.com) היא " Hard Coded ", זאת אומרת, כתובה ישירות אל תוך הקוד. מה הבעיה בכתיבה Hard Coded? Hard Coding נחשב ל anti-pattern , לא יעיל ולא פרודקטיבי, והכי חשוב - עלול לגרום לנו ללא מעט בעיות עתידיות. DRY - כאשר אנחנו כותבים משתנים וקבועים מסוימים אנחנו מסכנים את הקוד שלנו בחילול עיקרון (DRY (Do Not Repeat Yourself, שאומר שאסור לנו לחזור על עצמנו בקוד, בשום פנים ואופן! לא נרצה לכתוב שום שורה פעמיים! העיקרון מעודד אותנו להוציא כל פונקציונליות, פשוטה ככל שתהיה, לפונקציה נפרדת, וכך למנוע כתיבה חוזרת של קוד,...

בתור מפתחי אוטומציה (ותוכנה בכלל) אנחנו נתקלים בלא מעט בעיות.. אנחנו לא זוכרים syntax מסוים, נזרק לנו exception שאנחנו רואים פעם ראשונה או אפילו שגיאת קומפילציה שאנחנו לא מכירים. מה אנחנו עושים כדבר כזה קורה לנו? לרוב נפנה לדר' גוגל... הרי כל דבר שקרה לנו כבר קרה למישהו אחר בעבר, ובכל בעיה בה נתקלנו, אנחנו כנראה לא הראשונים שנתקלנו בה. ב-95% מהמקרים גוגל אכן פותר לנו את הבעיה. מה קורה כאשר אנחנו נתקלים  בבעיית Design  בקוד שלנו? אנחנו לא בטוחים כיצד לחבר את ה class-ים או שאנחנו יודעים שמה שעשינו "לא כל כך יפה" אבל אנחנו לא בטוחים כיצד לעשות זאת נכון. לשם כך נוצרו Design Patterns! Desing Pattens הן הפתרונות לבעיות שלנו בעיצוב התוכנה - אלו מעין  תבניות פתורות  וכל מה שנשאר למשתמש זה להתאים אותן למקרה שלו. במילים אחרות,  Design Patterns זה פשוט פתרון לבעיה בעיצוב הקוד. לאחר שהתקדמנו ולמדנו לא מעט בכל הקשור לעיצוב תוכנה מונחית עצמים, וכתיבת תרחישי אוטומציה ב Selenium ו - Appium, הגיע הזמן להמשיך ולהתקדם לנושאים הבאים. מה זה Factory Pattern? ...

לאחר שכבר למדנו לכתוב תרחישי בדיקות באמצעות Selenium   ו- Appium , וכן, למדנו את עקרונות העיצוב החשובים של תכנות מונחה עצמים. הגיע הזמן שנעשה צעד נוסף אל עבר בניית מערכת האוטומציה שלנו. כאשר אנחנו כותבים תרחיש בדיקה הוא יכול הרבה פעמים להיות מורכב ולכלול לא מעט שלבים בדרך לסיום. העניין הוא, שקשה (לפחות בתחילת הדרך) לגרום למערכת האוטומציה לעבוד ב-100% ולהיות נקייה מתקלות. לשם כך, בעבור כל פעולה שנעשה, נכתוב לתוך הלוג שלנו משפט שמתאר בקצרה את הפעולה שעשינו. כך, כאשר נחזור לקוד שלנו וננסה להבין איפה התרחיש/המערכת הנבדקת נפלה, נוכל להיות בטוחים בכל סדר הפעולות שהתבצע לפני הנפילה. ובנוסף, ולא פחות חשוב, כך נוכל לדאוג שאנחנו יודעים בדיוק מה קרה בתרחיש הבדיקה שהרצנו, ומה גרם לתקלה. במילים אחרות - כתיבה ללוג משלנו תקל עלינו מאוד בתחקור התרחיש או המערכת הנבדקת. אבל קודם כל... מה זה לוג? לוג הוא תוצר התיעוד של הפעולות שהרצנו אשר נבנה במהלך הריצה , בעבור כל פלט שנכתוב ללוג נוכל לראות את התאריך, השעה, הפונקציה ממנו נקראה הכתיבה ללוג ועוד הגדרות שניתנות לקונפיגור...

בתור מפתחי אוטומציה (ותוכנה בכלל) אנחנו נתקלים בלא מעט בעיות.. אנחנו לא זוכרים syntax מסוים, נזרק לנו exception שאנחנו רואים פעם ראשונה או אפילו שגיאת קומפילציה שאנחנו לא מכירים. מה אנחנו עושים כאשר דבר כזה קורה לנו? לרוב נפנה לדר' גוגל... הרי כל דבר שקרה לנו כבר קרה למישהו אחר בעבר, ובכל בעיה בה נתקלנו, אנחנו כנראה לא הראשונים שנתקלנו בה. ב-95% מהמקרים גוגל אכן פותר לנו את הבעיה. מה קורה כאשר אנחנו נתקלים  בבעיית Design  בקוד שלנו? אנחנו לא בטוחים כיצד לחבר את ה class-ים או שאנחנו יודעים שמה שעשינו "לא כל כך יפה" אבל אנחנו לא בטוחים כיצד לעשות זאת נכון. לשם כך נוצרו Design Patterns! Desing Pattens הן הפתרונות לבעיות שלנו בעיצוב התוכנה - אלו מעין  תבניות פתורות  וכל מה שנשאר למשתמש זה להתאים אותן למקרה שלו. במילים אחרות,  Design Patterns זה פשוט פתרון לבעיה בעיצוב הקוד. לאחר שהתקדמנו ולמדנו לא מעט בכל הקשור לעיצוב תוכנה מונחית עצמים, וכתיבת תרחישי אוטומציה ב Selenium ו - Appium, הגיע הזמן להמשיך ולהתקדם לנושאים הבאים. בהמשך לסדרה שלנו שלנו...

בתור מפתחי אוטומציה (ותוכנה בכלל) אנחנו נתקלים בלא מעט בעיות.. אנחנו לא זוכרים syntax מסוים, נזרק לנו exception שאנחנו רואים פעם ראשונה או אפילו שגיאת קומפילציה שאנחנו לא מכירים. מה אנחנו עושים כדבר כזה קורה לנו? לרוב נפנה לדר' גוגל... הרי כל דבר שקרה לנו כבר קרה למישהו אחר בעבר, ובכל בעיה בה נתקלנו, אנחנו כנראה לא הראשונים שנתקלנו בה. ב-95% מהמקרים גוגל אכן פותר לנו את הבעיה. מה קורה כאשר אנחנו נתקלים בבעיית Design בקוד שלנו? אנחנו לא בטוחים כיצד לחבר את ה class-ים או שאנחנו יודעים שמה שעשינו "לא כל כך יפה" אבל אנחנו לא בטוחים כיצד לעשות זאת נכון. לשם כך נוצרו Design Patterns! Desing Pattens הן הפתרונות לבעיות שלנו בעיצוב התוכנה - אלו מעין תבניות פתורות וכל מה שנשאר למשתמש זה להתאים אותן למקרה שלו. במילים אחרות, Design Patterns זה פשוט פתרון לבעיה בעיצוב הקוד. לאחר שהתקדמנו ולמדנו לא מעט בכל הקשור לעיצוב תוכנה מונחית עצמים, וכתיבת תרחישי אוטומציה ב Selenium ו - Appium, הגיע הזמן להמשיך ולהתקדם לנושאים הבאים. בפוסט של היום -  Page Objects דרישות ק...

אוקי, אז למדנו קצת על הארכיטקטורה הבסיסית והמוצגת למשתמש של Appium, ראינו  תרחיש בדיקה לדוגמה , למדנו  דרכים מגניבות למצוא אלמנטים וראינו שתי דרכים בהן נוכל לחבר את המכשיר למחשב לצורך הרצת אוטומציה. עכשיו כשאנחנו כבר יודעים דבר או שניים, הגיע הזמן שנבין איך הדברים עובדים קצת יותר לעומק. ראשית כל, אני ממליץ לכל קוראי הפוסט ללא יוצא מן הכלל, לקרוא קודם את  המדריך הראשוני של Appium בשביל להבין את הארכיטקטורה הבסיסית לפני שנצלול לעומק הדברים. קצת על הפילוסופיה של Appium מאחורי הרעיון של Appium עומדים 4 עקרונות עיקריים: 1. איננו צריכים לשנות שום דבר באפליקציה ולא לקמפל אותה מחדש, על מנת לכתוב לה תרחישי אוטומציה. 2. איננו צריכים לדבוק בשפת תכנות אחת מסוימת בכדי לכתוב ולהריץ בדיקות 3. תשתית אוטומציה לא צריכה להמציא את הגלגל בכל פעם מחדש בהיבט של ממשק השימוש (API) 4. תשתית אוטומציה צריכה להיות Open Source , דבר שיתן לה המון עוצמה. ה-Design של Appium אז איך המבנה של תשתית Appium משתלב עם הפילוסופיה שלו? עקרון מספר 1 , ממומש בכך שAppium משתמ...

אז בפעם הקודמת למדנו איך מחברים מכשיר אנדרואיד ל-ADB באמצעות כבל USB. העניין הוא שלא תמיד נרצה לעבוד בתצורה הזו, כבלי USB הרבה פעמים מסרבלים את ה-setup ודורשים משאבים שלא תמיד הכרחיים. לאחר שהמכשיר חובר למחשב בADB באמצעות כבל USB, נוכל לשלוט על המכשיר ולהורות לו לתקשר עם שרת הADB שעל המחשב באמצעות WiFi. איך עושים את זה? שלב 1: נחבר את המכשיר למחשב  באמצעות כבל ונוודא שיש לנו תקשורת ADB אליו כדאי בכל אופן להריץ את הפקודה adb usb  על מנת להיות בטוחים שאנחנו מחוברים בתצורת USB. שלב 2: נרים בשרת ה ADB שלנו את האופציה לתקשר על גבי WiFi באמצעות הפקודה - adb tcpip 5556 שלב 3: נדאג שהמכשיר והמחשב יהיו מחוברים לאותה רשת WiFi. ולאחר מכן נתשאל את המכשיר שלנו על ה-ip שקיבל ברשת באמצעות הפקודה -  adb shell ip -f inet addr show wlan0 שלב 4: כעת כשאנחנו יודעים את כתובת ה ip של המכשיר נוכל להגדיר את ה-ADB שלנו להתחבר למכשיר באמצעות WiFi על ידי הפקודה - adb connect 192.168.1.19:5556 ולאחר מכן נבצע שוב את הפקודה -  adb devi...