אוטומציית בדיקות Tox: מבט מעמיק על בדיקות מרובות סביבות לצוותים גלובליים

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

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

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

מהי בדיקת ריבוי סביבות ומדוע היא קריטית?

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

• גרסאות מתורגמן פייתון: האם הקוד שלך עובד על פייתון 3.8 כמו שהוא עובד על פייתון 3.11? מה לגבי פייתון 3.12 הקרוב?
• גרסאות תלות: היישום שלך עשוי להסתמך על ספריות כמו Django, Pandas או Requests. האם זה יישבר אם למשתמש יש גרסה קצת ישנה או חדשה יותר של חבילות אלה?
• מערכות הפעלה: האם הקוד שלך מטפל בנתיבי קבצים וקריאות מערכת כראוי ב-Windows, macOS ו-Linux?
• ארכיטקטורות: עם עליית מעבדי ARM (כמו Apple Silicon), בדיקות על ארכיטקטורות CPU שונות (x86_64, arm64) הופכות חשובות יותר ויותר.

ההצדקה העסקית לאסטרטגיית ריבוי סביבות

השקעת זמן בהקמת סוג זה של בדיקות אינה רק תרגיל אקדמי; יש לה השלכות עסקיות ישירות:

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

מציגים את Tox: מרכז הפיקוד האוטומטי שלך

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

כל זה נשלט על ידי קובץ תצורה פשוט ויחיד: tox.ini.

תחילת העבודה: התקנה ותצורה בסיסית

ההתקנה פשוטה עם pip:

pip install tox

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

דוגמה: tox.ini בסיסי

[tox]
min_version = 3.7
isolated_build = true
envlist = py38, py39, py310, py311

[testenv]
description = הפעל את חבילת הבדיקות הראשית
deps = pytest
commands = pytest

בואו נפרק את זה:

• [tox] סעיף: זה מיועד להגדרות Tox גלובליות.
• min_version: מציין את הגרסה המינימלית של Tox הנדרשת להפעלת תצורה זו.
• isolated_build: נוהג מומלץ מודרני (PEP 517) המבטיח שהחבילה שלך נבנית בסביבה מבודדת לפני שהיא מותקנת לצורך בדיקה.
• envlist: זהו הלב של בדיקות מרובות סביבות. זוהי רשימה מופרדת בפסיקים של הסביבות שברצונך ש-Tox ינהל. כאן, הגדרנו ארבע: אחת לכל גרסת פייתון מ-3.8 עד 3.11.
• [testenv] סעיף: זהו תבנית עבור כל הסביבות המוגדרות ב-envlist.
• description: הודעה מועילה המסבירה מה הסביבה עושה.
• deps: רשימה של תלויות הדרושות להפעלת הפקודות שלך. כאן, אנחנו רק צריכים pytest.
• commands: הפקודות להפעלה בתוך הסביבה הווירטואלית. כאן, אנו פשוט מריצים את מפעיל הבדיקות pytest.

כדי להפעיל זאת, נווט אל ספריית השורש של הפרויקט שלך בטרמינל שלך ופשוט הקלד:

tox

Tox יבצע כעת את השלבים הבאים עבור כל סביבה ב-`envlist` (py38, py39 וכו'):

1. חפש את מתורגמן הפייתון המתאים במערכת שלך (לדוגמה, `python3.8`, `python3.9`).
2. צור סביבה וירטואלית טרייה ומבודדת בתוך ספרייה .tox/.
3. התקן את הפרויקט שלך ואת התלויות המפורטות תחת `deps`.
4. בצע את הפקודות המפורטות תחת `commands`.

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

מבט מעמיק: יצירת tox.ini עוצמתי

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

סביבות גנרטיביות: המפתח לבדיקות קומבינטוריות

תאר לעצמך שיש לך ספרייה שצריכה לתמוך בגרסאות Django 3.2 ו-4.2, הפועלות על פייתון 3.9 ו-3.10. הגדרה ידנית של כל ארבעת הצירופים תהיה חוזרת על עצמה:

הדרך החוזרת על עצמה: envlist = py39-django32, py39-django42, py310-django32, py310-django42

Tox מספק תחביר גנרטיבי הרבה יותר נקי באמצעות סוגריים מסולסלים {}:

הדרך הגנרטיבית: envlist = {py39,py310}-django{32,42}

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

הגדרות מותנות גורם: התאמה אישית של כל סביבה

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

[tox]
envlist = {py39,py310}-django{32,42}

[testenv]
deps =
    pytest
    django32: Django>=3.2,<3.3
    django42: Django>=4.2,<4.3
commands = pytest

כאן, השורה `django32: Django>=3.2,<3.3` אומרת ל-Tox: "כלול תלות זו רק אם שם הסביבה מכיל את הגורם `django32`." באופן דומה עבור `django42`. Tox חכם מספיק כדי לנתח את שמות הסביבה (לדוגמה, `py310-django42`) ולהחיל את ההגדרות הנכונות.

זהו תכונה עוצמתית להפליא לניהול:

• תלויות שאינן תואמות לגרסאות פייתון ישנות/חדשות יותר.
• בדיקה מול גרסאות שונות של ספרייה מרכזית (Pandas, NumPy, SQLAlchemy וכו').
• התקנה מותנית של תלויות ספציפיות לפלטפורמה.

מבנה הפרויקט שלך מעבר לבדיקות בסיסיות

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

[tox]
envlist = py{39,310}, lint, typing, docs

[testenv]
deps = pytest
commands = pytest

[testenv:lint]
description = הפעל לינטרים (ruff, black)
basepython = python3.10
deps =
    ruff
    black
commands =
    ruff check .
    black --check .

[testenv:typing]
description = הפעל בודק סוגים סטטי (mypy)
basepython = python3.10
deps =
    mypy
    # כלול גם תלויות אחרות עם רמזים לסוגים
    django
    djangorestframework
commands = mypy my_project/

[testenv:docs]
description = בנה את התיעוד
basepython = python3.10
deps = sphinx
commands = sphinx-build -b html docs/source docs/build/html

הנה מה חדש:

• סעיפי סביבה ספציפיים: הוספנו `[testenv:lint]`, `[testenv:typing]` ו-`[testenv:docs]`. סעיפים אלה מגדירים הגדרות ספציפיות לסביבות בעלות השמות הללו, תוך עקיפת ברירות המחדל ב-`[testenv]`.
• basepython: עבור סביבות שאינן בדיקה כמו `lint` או `docs`, לעתים קרובות איננו צריכים להפעיל אותן בכל גרסת פייתון. `basepython` מאפשר לנו להצמיד אותן למתורגמן ספציפי, מה שהופך אותן למהירות וקובעות יותר.
• הפרדה נקייה: מבנה זה שומר על התלויות שלך נקיות. סביבת ה-`lint` מתקינה רק לינטרים; סביבות הבדיקה הראשיות שלך אינן זקוקות להן.

כעת תוכל להפעיל את כל הסביבות באמצעות `tox`, קבוצה ספציפית עם `tox -e py310,lint`, או רק אחת באמצעות `tox -e docs`.

שילוב Tox עם CI/CD לאוטומציה בקנה מידה גלובלי

הפעלת Tox באופן מקומי היא נהדרת, אבל הכוח האמיתי שלה משתחרר כאשר היא משולבת בצינור אינטגרציה רציפה/פריסה רציפה (CI/CD). זה מבטיח שכל שינוי בקוד יאושר אוטומטית מול מטריצת הבדיקות המלאה שלך.

שירותים כמו GitHub Actions, GitLab CI ו-Jenkins מושלמים לכך. הם יכולים להריץ את העבודות שלך על מערכות הפעלה שונות, ומאפשרים לך לבנות מטריצת תאימות OS מקיפה.

דוגמה: זרימת עבודה של GitHub Actions

בואו ניצור זרימת עבודה של GitHub Actions שמריצה את סביבות ה-Tox שלנו במקביל על פני Linux, macOS ו-Windows.

צור קובץ בכתובת .github/workflows/ci.yml:

name: CI

on: [push, pull_request]

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
        python-version: ['3.8', '3.9', '3.10', '3.11']

    steps:
    - name: בדוק את המאגר
      uses: actions/checkout@v3

    - name: הגדר את Python ${{ matrix.python-version }}
      uses: actions/setup-python@v4
      with:
        python-version: ${{ matrix.python-version }}

    - name: התקן את Tox
      run: pip install tox tox-gh-actions

    - name: הפעל את Tox
      run: tox -e py

בואו ננתח את זרימת העבודה הזו:

• strategy.matrix: זהו הליבה של מטריצת ה-CI שלנו. GitHub Actions תיצור עבודה נפרדת עבור כל שילוב של `os` ו-`python-version`. עבור תצורה זו, מדובר ב-3 מערכות הפעלה × 4 גרסאות פייתון = 12 עבודות מקבילות.
• actions/setup-python@v4: פעולה סטנדרטית זו מגדירה את גרסת הפייתון הספציפית הנדרשת לכל עבודה.
• tox-gh-actions: זהו תוסף Tox מועיל שממפה אוטומטית את גרסת הפייתון בסביבת ה-CI לסביבת ה-Tox הנכונה. לדוגמה, בעבודה הפועלת על פייתון 3.9, `tox -e py` יפתור אוטומטית להפעלת `tox -e py39`. זה חוסך לך מכתיבת לוגיקה מורכבת בסקריפט ה-CI שלך.

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

אסטרטגיות מתקדמות ושיטות עבודה מומלצות

העברת ארגומנטים לפקודות עם {posargs}

לפעמים אתה צריך להעביר ארגומנטים נוספים למפעיל הבדיקות שלך. לדוגמה, ייתכן שתרצה להפעיל קובץ בדיקה ספציפי: pytest tests/test_api.py. Tox תומך בכך עם החלפת {posargs}.

שנה את `tox.ini` שלך:

[testenv]
deps = pytest
commands = pytest {posargs}

כעת, אתה יכול להפעיל את Tox כך:

tox -e py310 -- -k "test_login" -v

ה--- מפריד בין ארגומנטים המיועדים ל-Tox מארגומנטים המיועדים לפקודה. כל מה שאחריו יוחלף עבור `{posargs}`. Tox יבצע: pytest -k "test_login" -v בתוך סביבת ה-`py310`.

שליטה במשתני סביבה

היישום שלך עשוי להתנהג אחרת בהתבסס על משתני סביבה (לדוגמה, `DJANGO_SETTINGS_MODULE`). ההנחיה `setenv` מאפשרת לך לשלוט בהם בתוך סביבות ה-Tox שלך.

[testenv]
setenv =
    PYTHONPATH = .
    MYAPP_MODE = testing

[testenv:docs]
setenv =
    SPHINX_BUILD = 1

טיפים להפעלות Tox מהירות יותר

ככל שהמטריצה שלך גדלה, הפעלות Tox יכולות להפוך לאיטיות. הנה כמה טיפים להאצת אותם:

• מצב מקביל: הפעל את `tox -p auto` כדי ש-Tox יפעיל את הסביבות שלך במקביל, תוך שימוש במספר ליבות ה-CPU הזמינות. זה יעיל מאוד במכונות מודרניות.
• צור מחדש סביבות באופן סלקטיבי: כברירת מחדל, Tox משתמשת מחדש בסביבות. אם התלויות שלך ב-`tox.ini` או ב-`requirements.txt` משתנות, אתה צריך לומר ל-Tox לבנות מחדש את הסביבה מאפס. השתמש בדגל היצירה מחדש: `tox -r -e py310`.
• אחסון במטמון של CI: בצינור ה-CI/CD שלך, אחסן במטמון את ספריית ה-.tox/. זה יכול להאיץ משמעותית את ההפעלות הבאות מכיוון שלא יהיה צורך להוריד ולהתקין תלויות בכל פעם, אלא אם כן הן ישתנו.

מקרים גלובליים בפועל

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

תרחיש 1: ספריית ניתוח נתונים בקוד פתוח

אתה מתחזק ספרייה פופולרית הבנויה על Pandas ו-NumPy. המשתמשים שלך הם מדעני נתונים ואנליסטים ברחבי העולם.

• אתגר: עליך לתמוך במספר גרסאות של Python, Pandas, NumPy, ולהבטיח שהוא עובד על שרתי Linux, מחשבים ניידים של macOS ושולחנות עבודה של Windows.
• פתרון Tox: envlist = {py39,py310,py311}-{pandas1,pandas2}-{numpy18,numpy19} `tox.ini` שלך ישתמש בהגדרות מותנות גורם כדי להתקין את גרסאות הספרייה הנכונות עבור כל סביבה. זרימת העבודה של GitHub Actions שלך תבדוק את המטריצה הזו על פני שלוש מערכות ההפעלה העיקריות. זה מבטיח שמשתמש בברזיל המשתמש בגרסת Pandas ישנה יותר יקבל את אותה חוויה אמינה כמו משתמש ביפן במחסנית העדכנית ביותר.

תרחיש 2: יישום SaaS ארגוני עם ספריית לקוח

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

• אתגר: צוות הפיתוח שלך משתמש בכלי עבודה מודרניים, אך ספריית הלקוחות שלך חייבת להיות תואמת לאחור לסביבות ארגוניות ישנות יותר.
• פתרון Tox: envlist = py38, py39, py310, py311 `tox.ini` שלך מבטיח שכל הבדיקות עוברות מול פייתון 3.8, שעשוי להיות התקן אצל לקוח מרכזי בצפון אמריקה. על ידי הפעלת זה אוטומטית ב-CI, אתה מונע ממפתחים להציג בטעות תכונות המשתמשות בתחביר או בספריות הזמינות רק בגרסאות פייתון חדשות יותר, ומונע כשלים יקרים בפריסה.

מסקנה: שלח בביטחון גלובלי

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

על ידי הגדרת הסביבות הנתמכות שלך בקובץ tox.ini בודד ושילובו עם צינור CI/CD, אתה יוצר שער איכות עוצמתי. שער זה מבטיח שהיישום שלך חזק, תואם ומוכן לקהל מגוון וגלובלי. אתה יכול להפסיק לדאוג לגבי בעיית "זה עובד על המכונה שלי" המפחידה ולהתחיל לשלוח קוד בביטחון שהוא יעבוד על המכונה של כולם, לא משנה היכן הם נמצאים בעולם.