Google is committed to advancing racial equity for Black communities. See how.

آزمایش بهترین روشهای TensorFlow

این موارد توصیه شده برای آزمایش کد در مخزن TensorFlow است .

قبل از شروع

قبل از مشارکت کد منبع در یک پروژه TensorFlow ، لطفاً پرونده CONTRIBUTING.md را در نسخه GitHub پروژه مرور کنید. (برای مثال ، به فایل CONTRIBUTING.md برای محتوای اصلی TensorFlow مراجعه کنید .) همه مشارکت کنندگان کد برای امضای توافق نامه مجوز مشارکت کننده (CLA) لازم هستند.

اصول کلی

فقط به آنچه در قوانین BUILD خود استفاده می کنید بستگی دارد

TensorFlow یک کتابخانه بزرگ است و بسته به بسته کامل هنگام نوشتن یک تست واحد برای زیرمجموعه های آن ، یک روش معمول است. با این حال ، این تجزیه و تحلیل مبتنی بر وابستگی bazel را غیرفعال می کند. این بدان معنی است که سیستم های ادغام مداوم نمی توانند هوشمندانه آزمایش های غیر مرتبط را برای اجرای قبل از ارسال / پس از ارسال حذف کنند. اگر فقط به زیر مدول هایی که در پرونده BUILD خود آزمایش می کنید وابسته باشید ، برای تمام توسعه دهندگان TensorFlow وقت و صرفه جویی در مقدار زیادی محاسبه انرژی خواهید کرد.

با این حال ، تغییر وابستگی ساختگی برای حذف اهداف کامل TF محدودیت هایی را برای آنچه می توانید در کد پایتون وارد کنید ایجاد می کند. دیگر نمی توانید از آزمون import tensorflow as 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 استفاده کنید. شما فقط باید خط زیر را در بالای پرونده BUILD اضافه کنید: load(“tensorflow/tensorflow.bzl”, “py_test”)

آگاه باشید که این آزمون در کجا اجرا می شود

هنگامی که شما یک آزمون می نویسید ، اگر ما متناسب با آن را بنویسیم ، اطلاعات تست ما می تواند از عهده آزمایشات شما بر روی CPU ، GPU و شتاب دهنده ها برآید. ما تست های خودکاری داریم که روی Linux ، macos ، windows اجرا می شوند و دارای سیستم هایی با GPU یا بدون GPU هستند. به سادگی باید یکی از ماکروهای ذکر شده در بالا را انتخاب کنید و سپس از برچسب ها برای محدود کردن محل اجرای آنها استفاده کنید.

  • برچسب manual آزمون شما را از اجرای هرجایی مستثنی می کند. این شامل اجرای آزمایشی دستی است که از الگوهایی مانند bazel test tensorflow/…

  • no_oss آزمون شما را در زیرساخت رسمی آزمون TF OSS مستثنی نمی کند.

  • no_mac یا no_windows می توان استفاده کرد تا آزمون شما را از مجموعه تست های مربوط به سیستم عامل خارج کند.

  • no_gpu برچسب no_gpu می توان برای حذف آزمون شما در مجموعه های تست GPU استفاده کرد.

آزمایشات را در مجموعه های آزمایشی مورد انتظار تأیید کنید

TF مجموعه های آزمایشی کاملاً کمی دارد. گاهی اوقات ، ممکن است برای تنظیم اشتباه بگیرند. ممکن است مشکلات مختلفی وجود داشته باشد که باعث شود آزمونهای شما در ساخت بی وقفه حذف شود. بنابراین ، باید بررسی کنید که آزمایشات شما مطابق انتظار انجام می شود. برای انجام این:

  • منتظر بمانید تا پیش از ارسال های Pull Request (PR) شما به پایان برسد.
  • برای دیدن بررسی وضعیت ، به پایین روابط عمومی خود بروید.
  • روی پیوند "جزئیات" در سمت راست هر چک Kokoro کلیک کنید.
  • برای یافتن اهداف جدیداً اضافه شده ، لیست "اهداف" را بررسی کنید.

هر کلاس / واحد باید پرونده آزمون واحد خود را داشته باشد

کلاسهای جداگانه آزمون به ما کمک می کند تا شکستها و منابع را بهتر جدا کنیم. آنها به خواندن پرونده های آزمایشی بسیار کوتاهتر و آسان تر منجر می شوند. بنابراین ، تمام پرونده های پایتون شما باید حداقل یک پرونده آزمایشی مربوطه داشته باشند (برای هر foo.py ، باید foo_test.py داشته foo_test.py ). برای تست های دقیق تر ، مانند تست های یکپارچه سازی که به تنظیمات مختلفی نیاز دارند ، افزودن پرونده های آزمایشی بیشتر خوب است.

سرعت و زمان دویدن

از خرد کردن باید تا حد ممکن کم استفاده شود

به جای خرد کردن لطفا در نظر بگیرید:

  • آزمایشات خود را کوچکتر کنید
  • اگر موارد بالا امکان پذیر نیست ، آزمایشات را تقسیم کنید

خرد کردن به کاهش تاخیر کلی یک آزمایش کمک می کند ، اما با شکستن آزمایش در اهداف کوچکتر ، می توان به همان نتیجه رسید. آزمایش های تقسیم به ما امکان کنترل دقیق تری در هر آزمون را می دهد ، اجرای قبل از ارسال غیر ضروری را به حداقل می رساند و باعث کاهش از دست دادن پوشش ساختمانی می شود که یک هدف کامل را از کار می اندازد به دلیل بد بودن آزمایشگاه. علاوه بر این ، خرد کردن هزینه های پنهانی را متحمل می شود که چندان واضح نیستند ، مانند اجرای همه کد های اولیه تست برای همه قطعات. این موضوع توسط تیمهای زیرفروجی به عنوان منبعی که بار اضافی ایجاد می کند ، به ما دامن زده اند.

تست های کوچکتر بهتر است

هرچه تست های شما سریعتر اجرا شود ، احتمال تست های شما در افراد بیشتر است. یک ثانیه اضافی برای آزمون شما می تواند ساعت ها وقت اضافی را که برای اجرای آزمون توسط توسعه دهندگان و زیرساخت های ما صرف شده جمع کنید. سعی کنید تست هایتان زیر 30 ثانیه (در حالت غیر انتخابی!) اجرا شود و آنها را کوچک کنید. فقط به عنوان آخرین چاره ، تست های خود را به عنوان متوسط ​​علامت بزنید. infra هیچ آزمایش بزرگی را به عنوان پیش شرط یا پس از ارسال انجام نمی دهد! بنابراین ، فقط اگر می خواهید جایی را که قرار است اجرا شود ، یک آزمون بزرگ بنویسید. چند نکته برای سریعتر انجام شدن آزمایش ها:

  • در آزمون خود تکرارهای کمتری از آموزش را انجام دهید
  • استفاده از تزریق وابستگی را در نظر بگیرید تا جایگزین وابستگی های سنگین سیستم تحت آزمایش با جعلی های ساده شود.
  • استفاده از داده های ورودی کوچکتر را در آزمایشات واحد در نظر بگیرید
  • اگر مورد دیگری کارساز نیست ، سعی کنید فایل آزمایشی خود را تقسیم کنید.

زمان آزمایش باید برای جلوگیری از پوسته پوسته شدن ، نیمی از زمان اندازه گیری آزمون باشد

با اهداف آزمایش bazel ، آزمونهای کوچک 1 دقیقه وقفه دارند. مهلت زمانی آزمون متوسط ​​5 دقیقه است. آزمایش های بزرگ فقط توسط تست TensorFlow انجام نمی شوند. با این حال ، بسیاری از آزمون ها از نظر زمانی که تعیین می کنند قطعی نیستند. به دلایل مختلف ممکن است هر چند وقت یکبار آزمایشات شما زمان بیشتری ببرد. و اگر آزمایشی را که به طور متوسط ​​50 ثانیه اجرا می شود ، علامت گذاری کنید ، اگر در دستگاهی با پردازنده مرکزی قدیمی برنامه ریزی شود ، تست شما پوسته پوسته می شود. بنابراین ، برای آزمایش های کوچک 30 ثانیه به طور متوسط ​​اجرا کنید. برای آزمایشات متوسط ​​به مدت 2 دقیقه و 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 در آزمایشات می تواند دلیل اصلی پوسته پوسته شدن باشد. به خصوص هنگام استفاده از چندین نخ ، استفاده از خواب برای انتظار یک موضوع دیگر هرگز قطعی نخواهد بود. این امر به این دلیل است که سیستم قادر به تضمین هرگونه ترتیب اجرای رشته ها یا فرایندهای مختلف نیست. بنابراین ، سازه های همگام سازی قطعی مانند mutex ها را ترجیح دهید.

پوسته پوسته شدن تست را بررسی کنید

Flakes باعث از دست رفتن ساعتهای ساخت و توسعه دهندگان می شود. تشخیص آنها دشوار است و اشکال زدایی آنها دشوار است. حتی اگر سیستم های خودکاری برای تشخیص پوسته پوسته شدن وجود داشته باشد ، آنها قبل از اینکه بتوانند با دقت تست های ضد عفونی کننده را بردارند ، باید صدها آزمایش را جمع کنند. حتی هنگامی که آنها را تشخیص می دهند ، آنها آزمایشات شما را پوسته پوسته می کنند و پوشش آزمایش از بین می رود. بنابراین ، نویسندگان آزمون باید هنگام نوشتن آزمون ها ، بررسی کنند که آیا تست های آنها پوسته پوسته است. این را می توان با اجرای آزمون خود با پرچم به راحتی انجام داد: --runs_per_test=1000

از TensorFlowTestCase استفاده کنید

TensorFlowTestCase اقدامات احتیاطی لازم مانند بذر دادن به همه مولدهای اعداد تصادفی را برای کاهش پوسته پوسته شدن تا حد ممکن انجام می دهد. همانطور که منابع شکنندگی بیشتری را کشف و برطرف می کنیم ، همه این موارد به TensorFlowTestCase اضافه می شوند. بنابراین ، هنگام نوشتن آزمایش برای tensorflow ، باید از TensorFlowTestCase استفاده کنید. TensorFlowTestCase در اینجا تعریف شده است: tensorflow/python/framework/test_util.py

تست های هرمسی بنویسید

آزمایش های هرماتیک به هیچ منبع بیرونی نیاز ندارند. آنها با همه چیزهایی که نیاز دارند بسته بندی شده است و فقط خدمات جعلی مورد نیاز خود را شروع می کنند. هر سرویس دیگری غیر از آزمون های شما منابعی برای عدم قطعیت است. حتی با 99٪ در دسترس بودن سرویس های دیگر ، شبکه می تواند پوسته پوسته شود ، پاسخ rpc به تأخیر بیفتد ، و ممکن است با یک پیام خطای غیر قابل توضیح روبرو شوید. خدمات خارج ممکن است GCS ، S3 یا هر وب سایتی باشد اما محدود به آنها نباشد.