כיצד להרכיב בדיקות מחדש לבסיסי קוד של ReactJS ללא בדיקות

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

אני אישית מפתח קוד reactjs כבר כמה שנים; אחד הפרויקטים הראשונים בקוד פתוח ששיתפתי נקרא testable . הוא שוחרר ב-2020 בערך, ומאז הקדשתי חלק ממסלול הלמידה שלי ל-reactjs.

לאחרונה, עבדתי על פרויקטים אחרים בקוד פתוח המתמקדים בחלק הבדיקות של דברים כגון json-tool ו- text-tool ; שני היישומים הם בקוד פתוח ונפרסים ב-Snapcraft. בנוסף לאלה, אני מריץ לעתים קרובות ניסויים במאגר שנקרא reactjs-playground . זה המקום שבו אני מתנסה בתכונות reactjs ומקדיש לכך את שעות הלמידה שלי. הניסיון שצברתי באותן שנים בפרויקטים במקור קרוב ובפרוייקטים בקוד פתוח נתן לי בסיס שמאפשר לי לזהות כמה מלכודות ויתרונות נפוצים.

מלכודות

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

רכיבים גדולים

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

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

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

מדינה גלובלית

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

ביישומי reactjs, חבילת ניהול המדינה הגלובלית בעבר בשימוש נרחב, redux, הפחיתה כעת את השימוש בה לטובת הקשרים קטנים יותר סביב גבולות באפליקציה. עם זאת, הקהילה חלקה דעות שונות לגבי הצורך להשתמש ב-redux לניהול מדינה גלובלי; זה הוביל לכמה בלוגים בנושא:

• אתה לא צריך להשתמש ב- Redux עבור אפליקציית React שלך .
• למה אתה לא צריך Redux יותר?

למרות דחיפה מהקהילה, react-redux, שהיא ספרייה המשמשת לקשירת redux לרכיבי reactjs, האימוץ שלה גדל בחמש השנים האחרונות בהתאם למגמות npm . ב-01 בפברואר 2025, ההורדות המוצגות ב-npm עבור redux הן 6,752,764.

אם אתה תוהה מהי האלטרנטיבה לכך, התשובה היא להגיב בהקשר ו-hooks עם שאילתות.

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

יתרונות

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

הקשרים

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

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

בדיקות שיפוץ

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

1. כתוב מקרה מבחן פשוט עבור הפונקציונליות הרצויה.
2. הפעל את מקרה הבדיקה וראה שהוא נכשל.

2.1. האם המבחן עבר?

 2.1.1 - Yes → Check if the feedback is correct 2.1.2 - No → Provide the dependency without questioning

3. חזור ל-1.

שימו לב: הגישה המתוארת כאן דומה למה שמתואר כמבחן האפיון שתואר על ידי מייקל Feathers ב-

עבודה יעילה עם ספר קוד מדור קודם.

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

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

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

בלב גישה זו עומד תהליך הלמידה; כל שלב בלימוד בסיס הקוד נלקח בחשבון.

לימודי תואר שני

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

בואו ניקח את Testable כדוגמה; זה יישום שנכתב לפני יותר מחמש שנים ב-reactjs ומשתמש באנזים לבדיקה. לפי התקן של היום, הספרייה שהשתלטה היא vitest או צחוק יחד עם ספריית הבדיקות. כדי להתאים את מקרי הבדיקה לניתנים לבדיקה ולנצל את היתרונות של LLMs, אנו יכולים להשתמש בטייס משנה כדי לעזור לנו עם ההרמה הכבדה.

Testable מורכב מחוויה gamified שיש לה מצב, רמות והתקדמות משתמש דרך אתגרים שונים. הרכיב המתואר בתמונה הבאה הוא הרכיב המשמש להצגת דיאלוגים ולנווט קדימה בהיסטוריה של החוויה. באמצעות Copilot עבור vscode, ביקשתי ממנו לכתוב מבחן עם קוד הייצור שאנו מעוניינים בו:

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

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

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

• היבוא אינו נכון; זה צריך תיקון כדי להצביע על הקובץ הנכון.
• ההגדרה לתוכן אינה נכונה; הקובץ לא היה אפשרי להפוך את התוכן לתקף למקרה המבחן.

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

אֶמְצָעִי

• מבחן אפיון