בדיקות

מצב הבדיקות בליבת WIZZO CMS: אין מערכת בדיקות אוטומטית, אילו כלי אימות קיימים, ורשימת בדיקה ידנית לפני כל שינוי

⏱ 4 דק' קריאה 787 מילים ערוך דף זה ב-GitHub

הדף הזה ישר לגבי המצב: בליבת WIZZO CMS אין היום בדיקות אוטומטיות. אין PHPUnit, אין בדיקות יחידה או אינטגרציה, אין בדיקות דפדפן ואין CI שרץ על Pull Request. שינוי נבדק ידנית, על אתר מקומי, לפני שהוא נכנס ל-main. הדף מפרט מה כן קיים כדי לבדוק, נותן רשימת בדיקה ידנית, ומסביר מה חסר.

שימו לב

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

מה אין#

דברמצב
בדיקות יחידה (PHPUnit)אין. התלות היחידה שמגיעה עם בדיקות היא ספריות צד שלישי (למשל PHPMailer), והן לא רצות כחלק מהליבה
בדיקות אינטגרציה על DBאין, ואין סכימה בריפו שאפשר להרים ממנה מסד בדיקות
בדיקות דפדפן (E2E)אין
ניתוח סטטי (phpstan, phpcs)אין
CIאין תיקיית .github/ ואין workflow
סביבת staging לעדכוני גרסהאין. גרסה שנכנסת ל-main ול-master זמינה לאתרים

הכוונה לסגור את הפער מתוארת במפת הדרכים.

כלי אימות שכן קיימים#

core_ping#

קונטרולר שמחזיר JSON קצר: האם הליבה עונה, מה הגרסה (מ-version.txt), האם ה-DB עונה לשאילתה SELECT 1, ואיזו גרסת PHP רצה. מנגנון עדכון הגרסה משתמש בו כדי לוודא שהליבה החדשה עולה לפני שהוא מחליט להישאר איתה (ראו עדכוני גרסה).

curl -s https://your-site.example/system/core_ping
{"ok":true,"version":"5.0.115","db":true,"php":"8.3.0"}

ok: true עם db: false אומר שהליבה עלתה אבל החיבור למסד נכשל.

דיבוג ניתוב#

מוסיפים ?__router_trace=1 לכל כתובת, ומקבלים את שלבי ההחלטה של ה-ROUTER: איזה כלל נתפס ולמה. הפלט מוצג רק למנהל מחובר, ל-localhost ולקריאות מאותו שרת. פירוט בדיבוג ניתוב.

לוג SQL#

הפרמטר log_sql עם הערך 1 (ב-PARAMS) גורם ל-DB לרשום כל שאילתה, עם ה-backtrace שקרא לה, אל הקובץ sqllog.txt בשורש האתר. אפשר לראות בו כמה שאילתות כל עמוד מריץ ואם השתנה משהו שלא התכוונתם אליו. הקובץ גדל במהירות, מפעילים רק לבדיקה ומכבים. ראו דיבוג SQL.

שימו לב
sqllog.txt מכיל את הערכים שנשלחו ל-DB, כולל נתוני משתמשים. לא מפעילים על אתר חי של לקוח, ולא משאירים את הקובץ נגיש מהרשת.

בדיקת תחביר#

  • ב-מנהל הקבצים של הניהול, כל שמירה של קובץ php, phtml, scss, css או json עוברת FileLint בשרת. שגיאת תחביר חוסמת את השמירה (אלא אם מכריחים). זו הגנה על אתר חי ולא תחליף לבדיקה לפני commit.
  • מהמחשב המקומי, על כל קובץ PHP ששניתם:
php -l api/core/controllers/my_controller.php

אפשר להריץ על כל הקבצים ששונו מול main:

git diff --name-only origin/main -- 'api/core/*.php' | xargs -r -n1 php -l

php -l בודק תחביר בלבד: לא קיום משתנים, לא סוגים ולא לוגיקה.

לוג שגיאות#

כל אתר מכיל מסך error_log בניהול, ובמצב פיתוח מקומי אפשר לקרוא את לוג השגיאות של PHP ישירות. אחרי כל בדיקה מסתכלים בו: אזהרות חדשות (Undefined variable, Undefined array key) הן באגים בפועל גם כשהעמוד נראה תקין.

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

מריצים על אתר מקומי שמקושר לריפו (ראו זרימת עבודה) עם DB שדומה לאתר אמיתי.

  1. תחביר: php -l על כל קובץ ששונה.
  2. עלייה: פותחים עמוד ציבורי אחד לפחות, ולא מקבלים מסך לבן או שגיאה.
  3. core_ping: מחזיר ok: true, db: true והגרסה החדשה.
  4. ניהול: נכנסים לפאנל, פותחים את המסך שנגעתם בו ועוד שניים אקראיים (רשימה, הוספה, עריכה, שמירה).
  5. המסלול שהשתנה: עוברים אותו מקצה לקצה, כולל מקרה ריק, מקרה עם קלט עברי ומקרה עם קלט שמכיל גרשיים ו-<script>.
  6. הרשאות: נכנסים עם משתמש שאינו מנהל או עם קבוצת הרשאות מוגבלת ובודקים שהפעולה נחסמת. נקודת כניסה חדשה נבדקת גם ללא התחברות.
  7. רב-לשוניות ו-RTL: אם נגעתם בתצוגה, בודקים עברית (RTL) ושפה נוספת אם האתר רב-לשוני.
  8. מטמון: מנקים מטמון (ראו ניקוי ותחזוקה) ובודקים שוב. שינוי שעובד רק מול מטמון ישן הוא באג.
  9. לוג שגיאות: אין שורות חדשות אחרי שלבים 2 עד 8.
  10. גרסה: version.txt הועלה (ראו שליחת שינויים).

שינוי שנוגע במנגנון העדכון עצמו (check_version, wizzo_update) נבדק בנוסף על אתר ניסיון נפרד, כולל תרחיש כשל: מכוונים את העדכון לגרסה שבורה בכוונה ומוודאים שה-rollback החזיר את הליבה הקודמת. אין לבדוק אותו על אתר לקוח.

בדיקת קוד של אתר (לא הליבה)#

כל מה שנכתב בתיקיית application/ של אתר, הקונטרולרים, התבניות והמודלים שלו, נבדק באותה רשימה, על העתק של האתר ולא על ייצור. הליבה אינה מספקת מסגרת בדיקות גם לקוד כזה. מי שרוצה בדיקות אוטומטיות לאתר שלו מוסיף PHPUnit ב-composer.json של האתר, מחוץ ל-system/core, כך שהעדכון הבא של הליבה לא ידרוס אותו.

מה חסר, ולאן זה הולך#

הפער מוכר ונמצא במפת הדרכים: מסד בדיקות שנבנה מסכימה בריפו, phpunit ו-php -l ב-CI על כל Pull Request, סריקת סודות, ובדיקת עלייה של ליבה חדשה מול אתר ניסיון לפני שהיא מפורסמת ללקוחות. עד אז, הרשימה הידנית למעלה היא הסטנדרט.

ראו גם#

מצאתם טעות או חוסר? תקנו את הדף או פתחו Issue בריפו. התיעוד נכתב מתוך הקוד של ליבה 5.0.115.