הדרך הנכונה לערוך בדיקות בפיתוח צד-לקוח

הבעיה העיקרית של הבדיקות בעולם הפיתוח היא שכולם בודקים את ה”איך” ולא את ה”מה”, אבל אפשר לפתור אותה בקלות כשעוברים להשתמש ב-Component Drivers

מאת גבריאל (גבי) גרינברג, מתכנת צד-לקוח ב-Wix Engineering 

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

כדי להמחיש עד כמה זה מורכב לבצע בדיקות TDD, מדגים גבי בהרצאתו כמה בדיקות על אפליקציית To Do List, ותוך כדי הצגת הבדיקות מתבהרת התמונה ועולות כמה בעיות מהותיות, שבהן:

  • שינוי שמות ה-class של האפליקציה יגרום לכך שהבדיקה תיכשל
  • לעתים קרובות הבדיקה איננה מובנת וקריאה
  • הבדיקה לרוב מורכבת ועמוסה בפרטים הקשורים ביישום

דרייבר לכל Component

זה הזמן לפשט את הקוד כמובן, וגבי מדגים גם כיצד ניתן להפוך אותו לקריא וברור בדרך קצת אחרת. לאחר הטיפול המתבקש ברפיטטיביות בקוד, מדגים גבי כיצד ליצור API לאפליקציה ובכך להסתיר למעשה את ה-implementation בתוך class, ולהפוך את הבדיקה המורכבת לקוד קצר, נקי וקריא. במלים אחרות, הוא יוצר driver לכל component. התוצאה המדהימה היא output ו-input מוגדרים היטב ו-component שאפשר סוף סוף להתייחס אליו כקוד.

יש לכך כמה יתרונות בולטים:

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

From Vanilla to React

אפשר אפילו לעשות ריפקטור של כל האפליקציה ולהעביר אותה מ-Vanilla ל-React. בעזרת הדגמה קצרה מסביר גבי כיצד ניתן להחליף טכנולוגיות כדי לטפל ב- State management ולהשאיר את כל השאר בדיוק אותו הדבר, כל עוד לא משנים את הפיצ’ר.

ולמה זה בעצם משנה?

גבי מדגיש כי טכניקת ה-Component Drivers לא נועדו רק כדי לאפשר החלפת טכנולוגיה בקלות (למרות שצריך להודות שזה בהחלט יתרון משמעותי), אלא על מנת לאפשר לנו לחשוב מה אנחנו רוצים לעשות, במקום איך אנחנו רוצים לעשות את זה. רק כשנסתיר את ה-implementation details ונפשט אותם, נוכל להיות באמת חופשיים לבדוק את האפליקציה עצמה. בהרצאתו מראה לנו גבי בדיוק עד כמה זה משתלם בטווח הארוך.

הכתבה בחסות Wix Engineering

Wix היא פלטפורמה לפיתוח Online presence באינטרנט, עם למעלה מ-100 מיליון משתמשים ב-190 מדינות. אנחנו ב-Wix Engineering מפתחים אפליקציות ענן מהמתקדמות בעולם, מקדישים זמן להתפתחות מקצועית ולמידה ולוקחים גם את ההנאה שלנו באותה הרצינות. תרבות הפיתוח שלנו מבוססת על חדשנות, יצירתיות ועל הצורך והרצון להמשיך לאתגר את עצמנו ואת גבולות הטכנולוגיה. אנו משתמשים בטכנולוגיות המתקדמות ביותר (Scala, Node, React, and Angular), בפלטפורמות מבוססות ענן (Google, Amazon and Azure) ומיישמים מתודולוגיות כגון Continuous Delivery ו-TDD. ל-Wix, שני מרכזי פיתוח בישראל - בתל-אביב ובבאר-שבע. מוזמנים לעקוב אחרינו גם ב-Twitter וב-Facebook.

כתב אורח

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

הגב

Be the First to Comment!

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
wpDiscuz

תגיות לכתבה: