هذه هي الممارسات الموصى بها لاختبار الكود في مستودع TensorFlow .
قبل أن تبدأ
قبل أن تساهم بكود المصدر في مشروع TensorFlow ، يرجى مراجعة ملف CONTRIBUTING.md في GitHub repo الخاص بالمشروع. (على سبيل المثال ، راجع ملف CONTRIBUTING.md الخاص بـ TensorFlow repo .) يُطلب من جميع المساهمين في التعليمات البرمجية التوقيع على اتفاقية ترخيص المساهم (CLA).
المبادئ العامة
تعتمد فقط على ما تستخدمه في قواعد BUILD الخاصة بك
TensorFlow عبارة عن مكتبة كبيرة ، وكان اعتمادًا على الحزمة الكاملة عند كتابة اختبار الوحدة للوحدات الفرعية الخاصة بها ممارسة شائعة. ومع ذلك ، فإن هذا يعطل التحليل القائم على التبعية bazel . هذا يعني أن أنظمة التكامل المستمر لا يمكنها القضاء بذكاء على الاختبارات غير ذات الصلة للتشغيل المسبق / بعد التقديم. إذا كنت تعتمد فقط على الوحدات الفرعية التي تختبرها في ملف BUILD الخاص بك ، فستوفر الوقت لجميع مطوري TensorFlow ، والكثير من القوة الحسابية القيمة.
ومع ذلك ، فإن تعديل تبعية البناء لحذف أهداف TF الكاملة يجلب بعض القيود على ما يمكنك استيراده في كود Python الخاص بك. لن تتمكن من استخدام import tensorflow as tf بيان import tensorflow as tf في اختبارات الوحدة الخاصة بك بعد الآن. لكن هذه مقايضة جديرة بالاهتمام لأنها تحمي جميع المطورين من إجراء آلاف الاختبارات غير الضرورية.
يجب أن تحتوي جميع التعليمات البرمجية على اختبارات وحدة
لأي كود تكتبه ، يجب عليك أيضًا كتابة اختبارات الوحدة الخاصة به. إذا كتبت ملفًا جديدًا foo.py ، فيجب عليك إجراء اختبارات الوحدة الخاصة به في foo_test.py وإرساله في نفس التغيير. تهدف إلى> 90٪ تغطية اختبار تزايدي لجميع التعليمات البرمجية الخاصة بك.
تجنب استخدام قواعد اختبار bazel الأصلية في TF
لدى TF الكثير من التفاصيل الدقيقة عند إجراء الاختبارات. لقد عملنا على إخفاء كل هذه التعقيدات في وحدات ماكرو bazel الخاصة بنا. لتجنب الاضطرار إلى التعامل مع هؤلاء ، استخدم ما يلي بدلاً من قواعد الاختبار الأصلية. لاحظ أن كل هذه العناصر محددة في tensorflow/tensorflow.bzl بالنسبة لاختبارات CC ، استخدم tf_cc_test ، tf_gpu_cc_test ، tf_gpu_only_cc_test . بالنسبة لاختبارات tf_py_test ، استخدم tf_py_test أو gpu_py_test . إذا كنت بحاجة إلى شيء قريب جدًا من قاعدة py_test الأصلية ، فيرجى استخدام القاعدة المحددة في tensorflow.bzl بدلاً من ذلك. ما عليك سوى إضافة السطر التالي أعلى ملف BUILD: load(“tensorflow/tensorflow.bzl”, “py_test”)
كن على علم بمكان إجراء الاختبار
عندما تكتب اختبارًا ، يمكن أن تهتم البنية التحتية للاختبار بإجراء اختباراتك على وحدة المعالجة المركزية ووحدة معالجة الرسومات والمسرعات إذا قمت بكتابتها وفقًا لذلك. لدينا اختبارات آلية تعمل على Linux ، و macos ، و windows ، والتي تحتوي على أنظمة مزودة بوحدات معالجة الرسومات أو بدونها. تحتاج ببساطة إلى اختيار أحد وحدات الماكرو المذكورة أعلاه ، ثم استخدام العلامات للحد من مكان تنفيذها.
ستستبعد العلامة
manualاختبارك من التشغيل في أي مكان. يتضمن ذلك عمليات تنفيذ الاختبار اليدوي التي تستخدم أنماطًا مثلbazel test tensorflow/…no_ossاختبارك من التشغيل في البنية التحتية لاختبار TF OSS الرسمية.no_macأوno_windowsالعلامات يمكن أن تستخدم لاستبعاد الاختبار من الأجنحة اختبار نظام التشغيل ذات الصلة.يمكن استخدام علامة
no_gpuلاستبعاد اختبارك من التشغيل في مجموعات اختبار GPU.
تحقق من تشغيل الاختبارات في مجموعات الاختبار المتوقعة
لدى TF عدد غير قليل من مجموعات الاختبار. في بعض الأحيان ، قد يكون الإعداد محيرًا. قد تكون هناك مشكلات مختلفة تؤدي إلى حذف اختباراتك من عمليات الإنشاء المستمرة. وبالتالي ، يجب عليك التحقق من تنفيذ اختباراتك على النحو المتوقع. لفعل هذا:
- انتظر حتى يتم تقديم الطلبات المسبقة في طلب السحب (PR) حتى الاكتمال.
- قم بالتمرير إلى الجزء السفلي من العلاقات العامة الخاصة بك لمعرفة عمليات التحقق من الحالة.
- انقر على رابط "التفاصيل" على الجانب الأيمن من أي شيك Kokoro.
- تحقق من قائمة "الأهداف" للعثور على أهدافك المضافة حديثًا.
يجب أن يكون لكل فئة / وحدة ملف اختبار الوحدة الخاص بها
تساعدنا فصول الاختبار المنفصلة في عزل الموارد والفشل بشكل أفضل. إنها تؤدي إلى ملفات اختبار أقصر وأسهل بكثير. لذلك ، يجب أن تحتوي جميع ملفات Python على ملف اختبار مطابق واحد على الأقل (لكل foo.py ، يجب أن يحتوي على foo_test.py ). لمزيد من الاختبارات التفصيلية ، مثل اختبارات التكامل التي تتطلب إعدادات مختلفة ، لا بأس من إضافة المزيد من ملفات الاختبار.
السرعة وأوقات التشغيل
يجب استخدام أقل قدر ممكن من التجزئة
بدلاً من التجزئة ، يرجى مراعاة ما يلي:
- جعل الاختبارات الخاصة بك أصغر
- إذا لم يكن ما سبق ممكنًا ، فقم بتقسيم الاختبارات
تساعد التقاسم على تقليل زمن الانتقال الإجمالي للاختبار ، ولكن يمكن تحقيق الشيء نفسه عن طريق تقسيم الاختبارات إلى أهداف أصغر. تمنحنا اختبارات الانقسام مستوى أدق من التحكم في كل اختبار ، مما يقلل من عمليات الإرسال غير الضرورية ويقلل من فقدان التغطية من buildcop الذي يعطل هدفًا بأكمله بسبب سوء التصرف في حالة الاختبار. علاوة على ذلك ، تتكبد التجزئة تكاليف مخفية ليست واضحة جدًا ، مثل تشغيل جميع رموز تهيئة الاختبار لجميع الأجزاء. تم تصعيد هذه المشكلة إلينا من قبل فرق الأشعة تحت الحمراء كمصدر يخلق حمولة إضافية.
الاختبارات الأصغر هي الأفضل
كلما زادت سرعة اختباراتك ، زادت احتمالية إجراء الأشخاص لاختباراتك. يمكن أن تتراكم ثانية واحدة إضافية للاختبار الخاص بك إلى ساعات من الوقت الإضافي الذي تقضيه في تشغيل اختبارك بواسطة المطورين والبنية التحتية لدينا. حاول أن تجعل اختباراتك تعمل في أقل من 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 في الاختبارات سببًا رئيسيًا للتقشر. خاصة عند استخدام خيوط متعددة ، فإن استخدام السكون لانتظار خيط آخر لن يكون حتميًا أبدًا. هذا بسبب عدم قدرة النظام على ضمان أي ترتيب لتنفيذ سلاسل أو عمليات مختلفة. لذلك ، تفضل بنيات التزامن الحتمية مثل كائنات المزامنة.
تحقق مما إذا كان الاختبار غير مستقر
تتسبب الرقائق في خسارة buildcops والمطورين لساعات طويلة. من الصعب اكتشافها ومن الصعب تصحيحها. على الرغم من وجود أنظمة آلية لاكتشاف التقلبات ، إلا أنها تحتاج إلى تجميع مئات من عمليات التشغيل الاختبارية قبل أن تتمكن من تحديد الاختبارات بدقة. حتى عندما يكتشفون ، فإنهم ينكرون اختباراتك ويفقدون تغطية الاختبار. لذلك ، يجب على مؤلفي الاختبار التحقق مما إذا كانت اختباراتهم غير مستقرة عند كتابة الاختبارات. يمكن القيام بذلك بسهولة عن طريق إجراء اختبارك باستخدام العلم: --runs_per_test=1000
استخدم TensorFlowTestCase
تتخذ TensorFlowTestCase الاحتياطات اللازمة مثل زرع جميع مولدات الأرقام العشوائية المستخدمة لتقليل التقشر قدر الإمكان. عندما نكتشف المزيد من مصادر التقشر ونصلحها ، ستتم إضافة كل هذه المصادر إلى TensorFlowTestCase. لذلك ، يجب عليك استخدام TensorFlowTestCase عند كتابة اختبارات Tensorflow. يتم تعريف TensorFlowTestCase هنا: tensorflow/python/framework/test_util.py
اكتب اختبارات محكمة
الاختبارات المحكمه لا تحتاج الى اي موارد خارجيه. إنهم مليئون بكل ما يحتاجون إليه ، ويبدأون فقط في أي خدمات مزيفة قد يحتاجون إليها. أي خدمات بخلاف الاختبارات الخاصة بك هي مصادر لعدم الحتمية. حتى مع توفر 99٪ من الخدمات الأخرى ، يمكن أن تتقشر الشبكة ، ويمكن أن تتأخر استجابة rpc ، وقد ينتهي بك الأمر برسالة خطأ لا يمكن تفسيرها. قد تكون الخدمات الخارجية ، على سبيل المثال لا الحصر ، GCS أو S3 أو أي موقع ويب.