ये टेन्सरफ्लो रिपॉजिटरी में परीक्षण कोड के लिए अनुशंसित अभ्यास हैं।
शुरू करने से पहले
इससे पहले कि आप एक TensorFlow परियोजना के लिए स्रोत कोड का योगदान करें, कृपया प्रोजेक्ट के GitHub रेपो में CONTRIBUTING.md फ़ाइल की समीक्षा करें। (उदाहरण के लिए, कोर TensorFlow रेपो के लिए CONTRIBUTING.md फ़ाइल देखें।) एक योगदानकर्ता लाइसेंस समझौते (CLA) पर हस्ताक्षर करने के लिए सभी कोड योगदानकर्ताओं की आवश्यकता होती है।
सामान्य सिद्धांतों
केवल इस बात पर निर्भर करें कि आप अपने BUILD नियमों में क्या उपयोग करते हैं
TensorFlow एक बड़ी लाइब्रेरी है, और पूर्ण पैकेज के आधार पर जब इसके सबमॉड्यूल्स के लिए एक यूनिट टेस्ट लिखना एक आम बात है। हालाँकि, यह bazel निर्भरता-आधारित विश्लेषण को अक्षम करता है। इसका मतलब यह है कि निरंतर एकीकरण प्रणाली समझदारी से पूर्व निर्धारित / पोस्टबमिट रन के लिए असंबंधित परीक्षणों को समाप्त नहीं कर सकती है। यदि आप केवल अपने BUILD फ़ाइल में परीक्षण कर रहे सबमॉडल्स पर निर्भर करते हैं, तो आप सभी TensorFlow Developers और बहुत अधिक मूल्यवान गणना शक्ति के लिए समय बचाएंगे।
हालाँकि, पूर्ण TF लक्ष्य को छोड़ने के लिए अपनी बिल्ड निर्भरता को संशोधित करने से आप अपने Python कोड में क्या आयात कर सकते हैं, इसके लिए कुछ सीमाएँ लाता है। अब आप अपने यूनिट परीक्षणों में import tensorflow as tf स्टेटमेंट के import tensorflow as tf में import tensorflow as tf का उपयोग नहीं कर पाएंगे। लेकिन यह एक सार्थक ट्रेडऑफ है क्योंकि यह सभी डेवलपर्स को हजारों अनावश्यक परीक्षण चलाने से बचाता है।
सभी कोड में यूनिट टेस्ट होना चाहिए
आपके द्वारा लिखे गए किसी भी कोड के लिए, आपको इसकी इकाई परीक्षण भी लिखना चाहिए। यदि आप एक नई फ़ाइल foo.py लिखते हैं, तो आपको इसके इकाई परीक्षण foo_test.py में करने foo_test.py और इसे उसी परिवर्तन के भीतर जमा करना चाहिए। अपने सभी कोड के लिए> 90% वृद्धिशील परीक्षण कवरेज का लक्ष्य रखें।
TF में देशी bazel परीक्षण नियमों का उपयोग करने से बचें
परीक्षण चलाने पर TF की बहुत सारी सूक्ष्मताएं होती हैं। हमने अपने bazel macros में उन सभी जटिलताओं को छिपाने का काम किया है। उन लोगों से निपटने से बचने के लिए, मूल परीक्षण नियमों के बजाय निम्नलिखित का उपयोग करें। ध्यान दें कि इन सभी को CC परीक्षण के लिए tensorflow/tensorflow.bzl . tensorflow/tensorflow.bzl में परिभाषित किया गया है, tf_cc_test , tf_gpu_cc_test , tf_gpu_only_cc_test उपयोग करें। अजगर परीक्षणों के लिए, tf_py_test या gpu_py_test उपयोग करें। यदि आपको वास्तव में देशी py_test नियम के करीब की आवश्यकता है, तो कृपया इसके बजाय टेंसोफ़्लो.बीज़ल में परिभाषित एक का उपयोग करें। आपको केवल BUILD फ़ाइल के शीर्ष पर निम्न पंक्ति जोड़ने की आवश्यकता है: load(“tensorflow/tensorflow.bzl”, “py_test”)
जानिए कि परीक्षा कहाँ पर होती है
जब आप एक परीक्षण लिखते हैं, तो हमारे टेस्ट इन्फ्रा सीपीयू, जीपीयू और त्वरक पर अपने परीक्षण चलाने का ख्याल रख सकते हैं यदि आप उनके अनुसार लिखते हैं। हमारे पास स्वचालित परीक्षण हैं जो लिनक्स, मैकोस, विंडोज़ पर चलते हैं, जिसमें जीपीयू के साथ या बिना सिस्टम हैं। आपको बस ऊपर सूचीबद्ध मैक्रोज़ में से एक को चुनना होगा, और फिर टैग को सीमित करने के लिए उपयोग करना होगा जहां उन्हें निष्पादित किया गया है।
manualटैग आपके परीक्षण को कहीं भी चलाने से बाहर कर देगा। इसमें मैन्युअल परीक्षण निष्पादन शामिल हैं जोbazel test tensorflow/…जैसे पैटर्न का उपयोग करते हैंbazel test tensorflow/…no_ossआपके परीक्षण को आधिकारिक TF OSS परीक्षण संरचना में चलने से बाहर कर देगा।no_macयाno_windowsटैग का उपयोग आपके परीक्षण को प्रासंगिक ऑपरेटिंग सिस्टम टेस्ट सूट से बाहर करने के लिए किया जा सकता है।GPU परीक्षण सुइट्स में आपके परीक्षण को बाहर करने के लिए
no_gpuटैग का उपयोग किया जा सकता है।
अपेक्षित परीक्षण सूट में सत्यापित परीक्षण चलाएं
TF में कुछ परीक्षण सूट हैं। कभी-कभी, वे सेट करने के लिए भ्रमित हो सकते हैं। अलग-अलग समस्याएं हो सकती हैं जिनके कारण आपके परीक्षणों को निरंतर बिल्ड से छोड़ा जा सकता है। इस प्रकार, आपको अपने परीक्षणों को सत्यापित करना चाहिए जैसा कि अपेक्षित था। यह करने के लिए:
- पूरा होने के लिए अपने पुल अनुरोध (पीआर) पर अपने presubmits के लिए प्रतीक्षा करें।
- स्थिति की जाँच देखने के लिए अपने पीआर के नीचे स्क्रॉल करें।
- किसी भी कोकोरो चेक के दाईं ओर "विवरण" लिंक पर क्लिक करें।
- अपने नए जोड़े गए लक्ष्यों को खोजने के लिए "लक्ष्य" सूची की जाँच करें।
प्रत्येक वर्ग / इकाई की अपनी इकाई परीक्षण फ़ाइल होनी चाहिए
अलग-अलग परीक्षण कक्षाएं हमें बेहतर अलगाव और संसाधनों में मदद करती हैं। वे परीक्षण फ़ाइलों को पढ़ने के लिए बहुत कम और आसान होते हैं। इसलिए, अपने सभी अजगर फ़ाइलें कम से कम एक इसी परीक्षण फ़ाइल होनी चाहिए (प्रत्येक के लिए foo.py , यह होना चाहिए foo_test.py )। अधिक विस्तृत परीक्षणों के लिए, जैसे एकीकरण परीक्षण जिसमें अलग-अलग सेटअप की आवश्यकता होती है, अधिक परीक्षण फ़ाइलों को जोड़ना ठीक है।
गति और समय चल रहा है
जितना हो सके शेयरिंग का इस्तेमाल करना चाहिए
कृपया विचार करने के बजाय विचार करें:
- अपने परीक्षणों को छोटा बनाना
- यदि उपरोक्त संभव नहीं है, तो परीक्षणों को विभाजित करें
साझाकरण एक परीक्षण की समग्र विलंबता को कम करने में मदद करता है, लेकिन परीक्षण को छोटे लक्ष्यों तक तोड़कर प्राप्त किया जा सकता है। बंटवारे परीक्षण हमें प्रत्येक परीक्षण पर एक महीन स्तर का नियंत्रण देता है, अनावश्यक प्रीबमिट रन को कम करता है और एक दुर्व्यवहार परीक्षण के कारण एक संपूर्ण लक्ष्य को अक्षम करने वाले बिल्डकॉप से कवरेज हानि को कम करता है। इसके अलावा, शार्पिंग छिपी हुई लागतों को पूरा करता है जो इतनी स्पष्ट नहीं हैं, जैसे कि सभी शार्क के लिए सभी परीक्षण आरंभीकरण कोड चलाना। अतिरिक्त अंक बनाने वाले स्रोत के रूप में इन्फ्रा टीमों द्वारा इस मुद्दे को आगे बढ़ाया गया है।
छोटे परीक्षण बेहतर हैं
आपके परीक्षण जितनी जल्दी चलते हैं, उतने ही अधिक लोग आपके परीक्षणों को चलाने में सक्षम होंगे। आपके परीक्षण के लिए एक अतिरिक्त सेकंड डेवलपर्स और हमारे बुनियादी ढांचे द्वारा आपके परीक्षण को चलाने में बिताए गए अतिरिक्त समय के घंटों तक जमा हो सकता है। अपने परीक्षणों को 30 सेकंड (नॉन-ऑप्ट मोड में!) के तहत चलाने की कोशिश करें, और उन्हें छोटा करें। केवल अंतिम उपाय के रूप में अपने परीक्षणों को माध्यम के रूप में चिह्नित करें। इन्फ्रा प्रेस्बिट्स या पोस्टूबमिट्स के रूप में कोई बड़ा परीक्षण नहीं चलाती है! इसलिए, केवल एक बड़ी परीक्षा लिखें यदि आप यह व्यवस्था करने जा रहे हैं कि यह कहां चलने वाला है। परीक्षण तेज करने के लिए कुछ सुझाव:
- अपने परीक्षण में प्रशिक्षण के कम पुनरावृत्तियों को चलाएँ
- सरल नकली के साथ परीक्षण के तहत प्रणाली की भारी निर्भरता को बदलने के लिए निर्भरता इंजेक्शन का उपयोग करने पर विचार करें।
- यूनिट परीक्षणों में छोटे इनपुट डेटा का उपयोग करने पर विचार करें
- यदि कुछ और काम नहीं करता है, तो अपनी परीक्षण फ़ाइल को विभाजित करने का प्रयास करें।
गुच्छे से बचने के लिए टेस्ट के समय को टेस्ट साइज के आधे समय का लक्ष्य बनाना चाहिए
bazel परीक्षण लक्ष्य के साथ, छोटे परीक्षणों में 1 मिनट का समय होता है। मध्यम परीक्षण का समय 5 मिनट है। बड़े परीक्षण सिर्फ TensorFlow परीक्षण इन्फ्रा द्वारा निष्पादित नहीं किए जाते हैं। हालांकि, कई परीक्षण निर्धारित नहीं होते हैं कि वे कितना समय लेते हैं। विभिन्न कारणों से आपके परीक्षणों में हर बार अधिक समय लग सकता है। और, यदि आप एक परीक्षण को चिह्नित करते हैं जो औसतन 50 सेकंड के लिए छोटा होता है, तो यह एक पुराने सीपीयू के साथ मशीन पर शेड्यूल करता है, तो आपका परीक्षण निकल जाएगा। इसलिए, छोटे परीक्षणों के लिए 30 सेकंड के औसत रनिंग समय का लक्ष्य रखें। मध्यम परीक्षणों के लिए औसत चलने के समय के 2 मिनट 30 सेकंड के लिए निशाना लगाओ।
नमूने की संख्या कम करें और प्रशिक्षण के लिए सहनशीलता बढ़ाएं
धीमी गति से चल रहे परीक्षण योगदानकर्ताओं को रोकते हैं। परीक्षणों में रनिंग प्रशिक्षण बहुत धीमा हो सकता है। अपने परीक्षणों को पर्याप्त रूप से तेज़ (2.5 मिनट अधिकतम) रखने के लिए अपने परीक्षणों में कम नमूनों का उपयोग करने में सक्षम होने के लिए उच्च सहिष्णुता को प्राथमिकता दें।
गैर-निर्धारकवाद और गुच्छे को हटा दें
निर्धारक परीक्षण लिखें
इकाई परीक्षण हमेशा निर्धारक होना चाहिए। टीएपी और गिटार पर चलने वाले सभी परीक्षणों को हर बार उसी तरह चलाना चाहिए, अगर कोई कोड परिवर्तन उन्हें प्रभावित नहीं करता है। यह सुनिश्चित करने के लिए, नीचे कुछ बिंदुओं पर विचार किया गया है।
हमेशा स्टोचैस्टी के किसी भी स्रोत को सीड करें
कोई भी यादृच्छिक संख्या जनरेटर, या स्टोचैस्टिसिटी के किसी भी अन्य स्रोत से चंचलता हो सकती है। इसलिए, इनमें से प्रत्येक को सीड किया जाना चाहिए। परीक्षणों को कम परतदार बनाने के अलावा, यह सभी परीक्षणों को प्रतिलिपि प्रस्तुत करने योग्य बनाता है। टीएफ परीक्षणों में आपको कुछ बीजों को सेट करने के विभिन्न तरीकों की आवश्यकता होती है:
# 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 का उपयोग करना चाहिए। TensorFlowTestCase को यहाँ परिभाषित किया गया है: tensorflow/python/framework/test_util.py
हर्मेटिक टेस्ट लिखिए
हार्मेटिक परीक्षणों को किसी भी बाहरी संसाधन की आवश्यकता नहीं है। वे अपनी जरूरत की हर चीज के साथ पैक किए जाते हैं, और वे बस किसी भी नकली सेवाओं को शुरू करते हैं जिनकी उन्हें आवश्यकता हो सकती है। आपके परीक्षण के अलावा कोई भी सेवाएं गैर-नियतत्ववाद के लिए स्रोत हैं। यहां तक कि अन्य सेवाओं की 99% उपलब्धता के साथ, नेटवर्क भड़क सकता है, आरपीसी प्रतिक्रिया में देरी हो सकती है, और आप एक अकथनीय त्रुटि संदेश के साथ समाप्त हो सकते हैं। बाहरी सेवाएँ, GCS, S3 या किसी वेबसाइट तक सीमित नहीं हो सकती हैं।