הגדרת בדיקות PHPUnit עבור מודולים של 1C-Bitrix: מ-bootstrap ועד CI/CD

מדוע מודולים של Битрикс נשברים בעת עדכון הליבה

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

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

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

בדיקת מודולים של Битрикс ללא בידוד מהסביבה לא תופסת את הפערים האלה: הקוד פונה למשתנים גלובליים, למסד נתונים אמיתי, לליבה חיה — והתוצאה תלויה במקום שבו הוא מורץ, ולא בלוגיקה של המודול עצמו.

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

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

מה נותן כיסוי בדיקות: אפקטים מדידים

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

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

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

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

ולבסוף, כיסוי בדיקות הופך את הערכת העבודה להוגנת יותר. רואים אילו תרחישים כבר מוגנים, ואילו נשענים על בדיקה ידנית — והיכן צוואר הבקבוק. בהמשך נפרט כיצד זה בנוי ברמת המודול של 1С-Битрикс: מ-bootstrap ועד להרצה בצינור הבנייה.

אפשרויות לארגון סביבת בדיקות

בחירת הסביבה קובעת עד כמה מהיר מעבר הבדיקות ועד כמה הוא משוחזר בין מחשבי המפתחים לבין הבנייה. עבור מודולים תחת 1С-Битрикс חשוב להחליט מראש היכן נמצא ליבת המוצר, היכן מסד הנתונים, וכיצד עולה ה-bootstrap של הבדיקות לפני ה-assert הראשון.

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

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

שלבי הטמעת בדיקות מודולים

הטמעת בדיקות היא לא "להתקין PHPUnit ולכתוב כמה בדיקות", אלא רצף של שלבים, שכל אחד מהם נשען על התוצאה של הקודם. להלן — איך זה נראה בפרויקטים עם מודולים של 1С-Битрикс, כולל כאלה שכבר עובדים בפרודקשן ולא יכולים לעצור לצורך העבודה.

איך בנוי התהליך

1. ביקורת מודולים ונקודות כשל. בודקים ממה מורכב הפרויקט: מודולים עצמאיים, התאמות ליבה, מטפלי אירועים, סוכנים, קומפוננטות. מסמנים מה בכלל ניתן לבדוק בבידוד, ומה תלוי באינפובלוק חי או בשירות חיצוני. בפלט — מפת מודולים עם עדיפויות: היכן שגיאה עולה ביוקר הרב ביותר.
2. הגדרת גבולות הבדיקה. מסכמים מה מכסים בבדיקות יחידה (לוגיקת חישובים, פרסינג, הרשאות גישה), ומה — בבדיקות אינטגרציה (עבודה עם בסיס נתונים, סנכרון עם 1С, REST). בלי שלב זה הבדיקות או משכפלות זו את זו, או לא תופסות תקלות אמיתיות.
3. הגדרת PHPUnit ו-bootstrap. מרימים סביבה: קונפיגורציה, טעינה אוטומטית של מחלקות המודול, החלפת ליבת Битрикс בסטבים במקומות שבהם בסיס הנתונים לא נדרש. הבדיקות מתחילות לרוץ באופן מקומי בפקודה אחת — זה הבסיס לכל ההמשך.
4. כתיבת הבדיקות האוטומטיות הראשונות. מתחילים ממודולים קריטיים, ולא מהכול בבת אחת. הבדיקות הראשונות צריכות לתפוס רגרסיות שכבר קרו — כך הצוות רואה במהירות תועלת ולא נוטש את היוזמה.
5. הרצת בדיקות אוטומטיות ב-CI. מחברים את ההרצה לקונ�вейер הבנייה: הבדיקות רצות על כל קומיט לענף, כשל חוסם מיזוג. בנפרד מגדירים דוח כיסוי, כדי לראות אילו מודולים עדיין לא מוגנים.
6. ייצוב וטיפול בכשלים. בשבועות הראשונים הבדיקות רועשות: התראות שווא, תלות בסדר ההרצה, נתונים לא יציבים. מנקים זאת עד למצב שבו הרצה אדומה מסמנת בעיה אמיתית.
7. מסירת תיעוד ותקנונים. מוסרים לצוות הלקוח תיאור ההרצה, כללים להוספת בדיקות חדשות, ניתוח שגיאות אופייניות. בהמשך המפתחים מתחזקים את הכיסוי בעצמם, בלי התמיכה הקבועה שלנו.

הסדר חשוב: אם מתחילים מ-CI בלי להבין את הגבולות, הקונ�вейер ייפול בכל שלב ויכבו אותו במהירות. אם מתחילים מבדיקות בלי להגדיר סביבה — הן לא ירוצו אצל מפתחים אחרים. תארו את המודולים שלכם ואת תהליך הבנייה הנוכחי — נחזור עם הערכה ותוכנית לפי שלבים.

ארטיפקטים: קונפיגורציות, סכמות, נהלים

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

• קונפיגורציית PHPUnit — קובץ phpunit.xml עובד עם חלוקה למערכי בדיקות (יחידתיות, אינטגרטיביות), נתיבים מוגדרים לקובץ ה-bootstrap וכללי החרגה של ספריות שירות.
• קובץ bootstrap לאתחול — מחבר את ליבת Битрикс, טעינה אוטומטית של המודול ותומכות בדיקה, כדי שהבדיקות ירוצו באופן זהה בכל מכונה ובצינור הבנייה.
• סכמת תלויות המודול — מפת קשרים בין מחלקות, שירותים ורכיבים חיצוניים עם סימון מה מבודד בבדיקות ומה דורש סביבה אמיתית.
• מדיניות הרשאות — נוהל זכויות להרצת בדיקות, קריאת לוגים ושינוי קונפיגורציה: מי מהצוות יכול לגעת במה ללא תיאום.
• תיעוד המודול — תיאור המבנה, נקודות ההרחבה ודוגמאות להרצת בדיקות למפתח חדש שנכנס לפרויקט.
• נוהל בדיקות — מתי מופעלות הבדיקות, אילו ענפים מוגנים ממיזוג ללא בדיקות ירוקות, כיצד מדווח כשל ומי אחראי על הניתוח.
• הוראות CI/CD — הגדרה שלב-אחר-שלב של הצינור: התקנת תלויות, הרצת מערכי הבדיקות, פרסום דוח כיסוי וחסימת הבנייה בעת רגרסיה.

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

מקרה בוחן: צמצום רגרסיות במודול ההחלפה

מה היה לפני ההטמעה

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

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

מה עשינו

הרכבנו bootstrap לבדיקות: הרימנו את הליבה של 1С-Битрикс בסביבה מבודדת, החלפנו את החיבור למערכת החיצונית ב-stub עם תגובות מוקלטות ותיעדנו את מצב בסיס הנתונים לבדיקות לפני כל הרצה. לאחר מכן כיסינו שלושה שכבות קריטיות — פירוק החבילה הנכנסת, מיפוי השדות וטיפול בשגיאות ההחלפה. הבדיקות הורצו באופן מקומי ובצינור הבנייה: כשל בכל שלב חסם את המיזוג.

מדדים לפני ואחרי

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

במה שונה בדיקת מודול מבדיקת אתר?

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

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

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

בידוד בדיקות משמעו שכל מערך בדיקות רץ בסביבה נקייה ואינו יורש נתונים מהקודם: בדיקה אינה "דולפת" לשכנה ואינה תלויה בסדר ההרצה.

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

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

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

ספקות טכניים ומגבלות

בדיקת מודולים של 1С-Битрикс נתקלת בשלוש מגבלות ממשיות: גרסת הליבה, מצב הקוד והסביבה. להלן כיצד אנו מתגברים עליהן בפועל, בלי אשליות לגבי פרויקט "אידיאלי".

יש לנו קוד legacy בלי הפרדה לשכבות. מה באמת אפשר לכסות בבדיקות?

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

הבדיקות ירוצו על מסד נתונים אמיתי או על עותק?

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

האם ניתן להריץ בדיקות אוטומטית בכל commit?

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

מה עם בדיקות שנוגעות בליבת Битрикс ישירות?

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

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

נדון במשימה שלכם ונחזור עם תוכנית

כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים להבין את גבולות המשימה: אילו מודולים מכסים, מה כבר קיים במאגר ובאיזה שלב נמצא הפרויקט. לאחר מכן נתאים ציפיות לגבי היקף — מ-bootstrap והבדיקות הראשונות ועד לקונ�вейер מלא עם הרצה על כל שינוי.

מה כדאי להכין לשיחה:

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

לאחר הניתוח נחזור עם הערכת הפרויקט: הרכב העבודות, שלבים, נקודות בקרה ואפשרויות — למשל, להתחיל ממודולים קריטיים ולהרחיב את הכיסוי, או להניח מיד קונ�вейер מלא. הצעד הבא — שיחת זום קצרה על הנתונים שהוכנו, שלאחריה נקבע את התוכנית ונתחיל. תארו את המשימה — נדון בפרטים ונציע פתרון לפרויקט שלכם.