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

אלה הנוהגים המומלצים לבדיקת קוד במאגר TensorFlow .

לפני שתתחיל

לפני שתתרום קוד מקור לפרויקט TensorFlow, אנא עיין בקובץ CONTRIBUTING.md ברשימת GitHub של הפרויקט. (לדוגמה, עיין בקובץ CONTRIBUTING.md עבור ריבוי הליבה של TensorFlow .) כל תורמי הקוד נדרשים לחתום על הסכם רישיון תורם (CLA).

עקרונות כלליים

תלוי רק במה שאתה משתמש בכללי ה- BUILD שלך

TensorFlow היא ספרייה גדולה, ובהתאם לחבילה המלאה בעת כתיבת מבחן יחידה עבור תת-המודולים שלה היה נוהג נפוץ. עם זאת, הדבר מבטל את הניתוח מבוסס התלות של bazel . המשמעות היא שמערכות אינטגרציה רציפות אינן יכולות לחסל בצורה חכמה מבחנים שאינם קשורים לריצות הגשה חוזרת / פוסט הגשה. אם אתה רק תלוי submodules כי אתה בודק ב שלך BUILD קובץ, תוכלו לחסוך זמן עבור כל מפתחי TensorFlow, והרבה כוח חישוב ערך.

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

כל הקוד צריך לכלול בדיקות יחידה

עבור כל קוד שאתה כותב, עליך לכתוב גם את מבחני היחידות שלו. אם אתה כותב קובץ חדש foo.py , עליך למקם את בדיקות היחידות שלו ב- foo_test.py ולהגיש אותו בתוך אותו שינוי. כוון ליותר מ 90% כיסוי בדיקות מצטבר לכל הקוד שלך.

הימנע משימוש בכללי בדיקה מקוריים של בזל ב- TF

ל- TF יש הרבה דקויות בעת הפעלת בדיקות. עבדנו על מנת להסתיר את כל המורכבויות הללו במקרו הבסיסי שלנו. כדי להימנע מהצורך להתמודד עם אלה, השתמש בהמשך במקום בכללי הבדיקה המקוריים. שים לב שכל אלה מוגדרים ב- tensorflow/tensorflow.bzl לבדיקות CC, השתמש ב- tf_cc_test , tf_gpu_cc_test , tf_gpu_only_cc_test . לבדיקות פיתון, השתמש ב- tf_py_test או gpu_py_test . אם אתה זקוק למשהו ממש קרוב לכלל py_test המקורי, השתמש במקום זאת המוגדר ב- tensorflow.bzl. אתה רק צריך להוסיף את השורה הבאה בחלק העליון של קובץ ה- load(“tensorflow/tensorflow.bzl”, “py_test”) : load(“tensorflow/tensorflow.bzl”, “py_test”)

היה מודע לאן מבוצע הבדיקה

כשאתה כותב מבחן, אינפרא הבדיקה שלנו יכול לדאוג להריץ את הבדיקות שלך על מעבד, GPU ומאיצים אם אתה כותב אותם בהתאם. יש לנו בדיקות אוטומטיות שפועלות על Linux, Macos, Windows, שיש להם מערכות עם או בלי GPUs. אתה פשוט צריך לבחור אחד מהמקרואים המפורטים לעיל, ואז להשתמש בתגים כדי להגביל את המיקום בו הם מבוצעים.

  • תג manual לא יכלול את הבדיקה שלך לרוץ בכל מקום. זה כולל ביצוע בדיקות ידניות המשתמשות בדפוסים כגון bazel test tensorflow/…

  • no_oss לא יכלול את הבדיקה שלך no_oss הבדיקה הרשמית של TF OSS.

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

  • ניתן להשתמש בתג no_gpu כדי לא לכלול את הבדיקה שלך no_gpu בסוויטות בדיקת GPU.

אמת את המבחנים המופעלים בסוויטות הבדיקה הצפויות

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

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

לכל מחלקה / יחידה צריך להיות קובץ בדיקת יחידה משלה

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

זמני מהירות וזמן ריצה

יש להשתמש בגריסה כמה שפחות

במקום להתנתק אנא שקול:

  • הקטנת המבחנים שלך
  • אם האמור לעיל אינו אפשרי, חלק את הבדיקות

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

מבחנים קטנים יותר טובים יותר

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

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

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

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

צמצם את מספר הדגימות והגדיל את הסובלנות לאימון

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

בטל אי-דטרמיניזם ופתיתים

כתוב מבחנים דטרמיניסטיים

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

תמיד זרע כל מקור לסטוכסטיות

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

# Python RNG
import random
random.seed(42)

# Numpy RNG
import numpy as np
np.random.seed(42)

# TF RNG
from tensorflow.python.framework import random_seed
random_seed.set_seed(42)

הימנע משימוש sleep בבדיקות מרובות הברגה

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

בדוק אם הבדיקה רעועה

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

השתמש ב- TensorFlowTestCase

TensorFlowTestCase נוקט אמצעי זהירות הכרחיים כגון זריעת כל מחוללי המספרים האקראיים המשמשים להפחתת קשקשים ככל האפשר. כאשר אנו מגלים ומתקנים מקורות קשקשים נוספים, כל אלה יתווספו ל- TensorFlowTestCase. לכן, עליך להשתמש ב- TensorFlowTestCase בעת כתיבת בדיקות עבור tensorflow. TensorFlowTestCase מוגדר כאן: tensorflow/python/framework/test_util.py

כתוב בדיקות הרמטיות

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