ונפתח בשאלה, מי שמע על Philip Jägenstedt ? מי מכיר את Maksim Sadym ? או את Henrik Skupin ?
אני מניח שרובכם לא שמעתם בכלל על האנשים הללו. ובכן, אז כדאי שתכירו, כי הם אלו האנשים שמעצבים לנו את העתיד. יותר נכון את עתיד האוטומציה (לא, לא החברה בה אני עובד, אלא העתיד של הבדיקות האוטומטיות), ועוד יותר נכון – את העתיד של האוטומציה על הדפדפנים. והעתיד, לפי כל מפתחי ספריות הקוד והפריימוורקים שאנו מורידים ומשתמשים בהם (Selenium, Puppeteer, Cypress ועוד…) הולך לכיוון פרוטוקול ה-WebDriver BiDi.
קבוצה של מפתחים מוכשרים יושבים בימים אלו ומעצבים את הפרוטוקול הזה, אותו פרוטוקול שנכון להיום הוא עדיין בגרסת טיוטה (Draft Edition), הולך להיות הפרוטוקול הראשי עימו כל כלי האוטומציה יעבדו, הוא הולך להיות הסטנדרד ועליו אנו נעביר את הפקודות ללחוץ על כתפור, להפעיל Event כזה או אחר על הדפדפן, או לקושש לוגים של תעבורת הקליינטים שלנו. אנחנו עוד נחזור אליהם בהמשך הפוסט…
אויי לעזאזל, עשיתי לכם כבר את הספויילר, ואולי הייתי צריך לשמור את הבאזוורד החדש הזה לסוף, אבל אני כל כך מתלהב מלכתוב על זה, כך שלא יכולתי להתאפק 🙂
בואו נתחיל מהתחלה (וגם קצת היסטוריה)…
הרי כשאנחנו באים ומבצעים פעולה, נגיד בסלניום על אלמנט, אנחנו צריכים קודם להשתמש באיזושהו סוג של חיבור או אופן העברת הנתונים מאיתנו לדפדפן לדוגמא. לשם כך אנו צריכים לעבוד עם פרוטוקול תקשורת. פרוטוקול התקשורת ה-HTTP הינו הבחירה הברורה מאליה, אבל מה קורה לגביי התקשורת בין הדפדפן לפעולות שלנו עם סלניום ? ובכן, מעל פרוטוקול ה-HTTP מימשו עבורינו פרוטוקול נוסף שנקרא: JSON Wire Protocol פרוטוקול זה הינו RESTful WebService ודרכו אנו ניגשים לדבר מול ה-WebDriver או שרת ה-RemoteWebDriver ע"י שליחת מידע בתצורה של JSON.
ה-JSON למי שלא מכיר, נראה ככה (דוגמא שלא קשורה לסלניום):
{ "Person":{ "FirstName":"Saed", "LastName":"Jaber", "ID":"12345", "Country" : "Isreal", "Email" : "saed@example.com" } }
השימוש בפרוטוקול זה החל עם פיתוח הסלניום בגרסאותיו הראשונות (עוד החל מ-Selenium 1.0 שנקרא גם Selenium Remote Control), בחרו בו בכדיי לממש תקשורת של לקוח-שרת (Selenium RC) עם כל יתרונותיות כמו:
- כתיבת מקרי הבדיקה שלנו בכל שפת תכנות שנרצה
- אפשרות להריץ את הבדיקות גם בצורה מקומית וגם בצורה מרוחקת (RemoteWebDriver)
- הרצת הבדיקות על שירותי ענן כדוגמת BrowserStack ודומיהם אשר מושתתים על ה-Selenium Grid
- עבודה מול דפדפנים שונים בעזרת עבודה מול דרייברים שונים
כל הפעולות הללו, עם סינכרון בין השרת ללקוח דורשות איזשהו סטנדרט והסטנדרט (אוסף של ספציפיקציות) הזה הגיע בתצורה של פרוטוקול ה-JSON WIRE
במסגרת פרוטוקול זה, המפתחים יצרו עבורינו כמה אובייקטים של JSON לעבודה כמו ה-WebElement JSON Object או ה-Capabilities שחלקנו מכירים בעבודה להגדרות שונות של איתחול הדרייבר
עברו שנים, התבגרנו, כך גם הקליינטים אותם אנו בודקים, כך גם כלי האוטומציה…
והחל מגרסת סלניום 3.8, קבוצת הפיתוח של סלניום התחילו להחליף לאט לאט את פרוטוקול ה-JSON Wire המיושן לאחד חדש, אחד שהולך לפי סטנדרטיזציה (תקינה) של W3C , בכל גרסה הוחלפו בסלניום יותר ויותר פיצ'רים שיעבדו מעל הפרוטוקול החדש על חשבון הישן. לפרוטוקול החדש קראו, איך לא – WebDriver W3C. גרסת סלניום 3.141.59 (הגרסה האחרונה של 3) החליפה כבר את רוב הפרוטוקול וכאשר גרסת סלניום 4 יצאה היא החליפה לגמרי את את ה-JSON WIRE
לפרוטוקול ה-WebDriver נכתבו Endpoints , קריאות REST API נשלחו לדרייברים עם פקודות. למשל בקשת POST /session לאותו הדרייבר כדי לאתחל אותו או לחילופין שליחת הבקשה: POST /session/:sessionId/element/:id/click בשביל ללחוץ על אלמנט וכו'…
רשימה של בקשות כאלו בפרוטוקול ה-WebDriver ניתן לראן כאן: https://github.com/jlipps/simple-wd-spec
ואז הגיע החלק הכיפי…
החל מגרסת Selenium 4 הארכיטקטורה השתנתה כך שכעת סלניום תומך גם בפרוטוקול נוסף, פרוטוקול שבעיקרון מגיע מעולם הפיתוח אבל למה לא לרתום אותו גם לצרכי הבדיקות ?
לפרוטוקול הזה קוראים Chrome DevTools Protocol או בקיצור CDP וכלי אוטומציה אחרים כבר עובדים מולו (כמו ה-Cypress או ה-Puppeteer), חדי העין או סתם משועממים כמוני שאוהבים לחקור את ספריות הקוד של סלניום, ישימו לב כי התווספה לנו מחלקה חדשה בסלניום 4 אשר תומכת בפרוטוקול זה, היא נקראת ChromiumDriver
מה זה נותן לנו ? המון. פרוטוקול ה-DevTools פתאום יודע להפוך את סלניום מסתם כלי אוטומציה לבדיקות GUI לכלי שיודע לעבוד גם מתחת לפני השטח, עם פרוטוקול זה אנו יכולים לאסוף לוגים, לסמלץ GeoLocation, לעבוד במצב Offline , לסמלץ TimeZone שונים, מטריקות של ביצועים ועוד…
ובכך, בעזרת תמיכה בפרוטוקול ה-DevTools סלניום מצליח לסגור את הפער מול כלי האוטומציה המודרניים כמו Puppeteer או Playwright שאצלם יכולות אלו קיימות עוד מההתחלה (כן, גם הם עובדים עם ה-Chrome DevTools Protocol)
יתרונותיו של ה-CDP ברורים. הוא מהיר, מאוד מהיר. הוא מתועד כהלכה (גוגל, נו מה ?), יש לו קהילת מפתחים גדולה והוא מספק שליטה נרחבת על דפדפנים מבוססי מנוע הכרומיום
הבעיה העיקרית של ה-CDP היא שהוא לא תומך בכל הדפדפנים (רק אלו שמבוססים מעל ה-Chromium), כך שהוא אינו יכול להיות הסטנדרט בתעשייה.
בעיה נוספת היא שהוא לא נכתב ספציפית עבור בדיקות אלא יותר עבור פיתוח, זה אומר שצריך להשקיע מאמצים לפעולות של בדיקות E2E למשל (דוגמא למעבר מול פריימים שונים)
העתיד כבר כאן:
התפקיד של ה-WebDriver BiDirectional הוא להוות תחליף ל-CDP המוגבל לדפדפנים מסויימים, והוא כאן כדי לקבוע פרוטוקול סטנדרט חדש לפעולות אוטומטיות על דפדפנים מכל הסוגים, שמו – Bi Directional נובע מכך שהוא נע לשני הכיוונים של כלי האוטומציה \ דפדפנים על ידי WebSockets או Pipes שגם הם פרוטוקולי תקשורת
הרעיון של WebDriver BiDirectional או בקיצור WebDriverBiDi הוא לקחת את הטוב מ-2 עולמות הפרוטוקולים: ה-WebDriver וה-CDP, שזה אומר פרוטוקול מהיר עם תמיכה נרחבת ואפשרויות בלתי מגבלות ב-low level תוך גם תמיכה בבדיקות ולא רק פיתוח.
החלק היפה כאן הוא שכל הספקים של הדפדפנים עובדים בשיתוף פעולה מול מפתחי הפרוטוקול החדש הזה, ספקים כמו: Apple, Google, Microsoft, Mozilla, SauceLabs, BrowserStack…
ומי הם מפתחי הפרוטוקול החדש הזה ? ובכן, בואו נחזור לשמות שמופיעים בתחילת הפוסט, את רשימת מפתחי הפרוטוקול והפרוטוקול עצמו (שהוא Open Source) ניתן למצוא, איך לא ב-GitHub בכתובת: https://github.com/w3c/webdriver-bidi
נכון לכתיבת שורות אלו, פרוטוקול זה הוא עדיין בגדר של טיוטה (Draft) כאמור, כך שאני מתאר לעצמי כי שיחות מתבצעות בין החבר'ה הללו בתמונה מול החברות הגדולות המוזכרות למעלה.
למעשה התקינה הזאת של ה-WebDriver BiDi תבטיח לנו שלא משנה מה בעתיד, כאשר חברה מסויימת תרצה לפתח דפדפן חדש או איזשהו סוג של קליינט מבוסס דפדפן, היא תצטרך ללכת לפי אותה תקינה וליישר קו עם האחרים, זה אומר לנו (מפתחי האוטומציה) חיים קלים יותר בתמיכה על קליינטים שונים
לסיום אשתמש בסלוגן של בזק מלפני כמה שנים: "העתיד נראה טוב, העתיד נראה WebDriver BiDi
