How Guru’s Engineers Use Cypress for Better Burn Testing

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

תוכן העניינים

קישור לטקסט

אנחנו מתמקדים בשיתוף ידע בGuru, וכשאנחנו מגלים משהו חדש ומועיל, אנחנו רוצים שהעולם ידע על כך! צוות ההנדסה שלנו משתמש בCypress בתהליך הבדיקה ואיכות המוצר שלהם. הם גילו דרך חדשה לבצע בדיקות בעירה טובות יותר, והם רוצים לשתף את התהליך החדש והמוגבר שלהם עם מהנדסים ובודקים אחרים.

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

Ryan%20and%20Jack%20Talk%20About%20Cypress.png

מה אנחנו מחפשים בבדיקות מסורתיות

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

לדוגמה, ייתכן שיש בדיקה שאומרת, "לך לחלק הזה באפליקציה > הוסף כרטיס Guru חדש > צפה במצב לאחר יצירה". אם מצב הח/loading של יצירת כרטיס מחכה ליותר מדי זמן וCypress מתחיל לחפש את מצב לאחר היצירה לפני שהוא מופיע, הבדיקה הזו עשויה להיכשל (בדרך כלל, הבדיקה הזו תעבור). אם זה עובר פעם אחת על בקשה למשיכה, אנחנו מסוגלים למזג קוד שעלול לפעמים להיכשל. אבל לא נדע אם זה נכון; בדיקה שעוברת איננה ערובה שהקוד תקין.

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

איך בדיקות בעירה עוזרות

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

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

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

כדי למצוא את הקבצים שאנחנו מחפשים, אנחנו משתמשים בgit diff על הענף הנוכחי ומספקים את הפלט כפרמטר לכלי שנקרא cypress-repeat שמאפשר לנו להריץ את הבדיקות האלה כל מספר פעמים שצוין, ובכך להוסיף בדיקות בעירה כשלב בסט הבדיקות שלנו מקצה לקצה.

ההישג

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

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