Bunlar, TensorFlow deposundaki kodu test etmek için önerilen uygulamalardır.
Başlamadan önce
Bir TensorFlow projesine kaynak koduna katkıda bulunmadan önce, lütfen projenin GitHub deposundaki CONTRIBUTING.md dosyasını gözden geçirin. (Örneğin , çekirdek TensorFlow deposu için CONTRIBUTING.md dosyasına bakın.) Tüm koda katkıda bulunanların bir Katılımcı Lisans Sözleşmesi (CLA) imzalaması gerekir.
Genel İlkeler
Yalnızca YAP kurallarınızda ne kullandığınıza bağlı
TensorFlow büyük bir kitaplıktır ve alt modülleri için bir birim testi yazarken tam pakete bağlı olarak yaygın bir uygulama olmuştur. Ancak bu, bazel bağımlılığına dayalı analizi devre dışı bırakır. Bu, sürekli entegrasyon sistemlerinin ön gönderme / gönderme sonrası çalıştırmalar için ilgisiz testleri akıllıca ortadan kaldıramayacağı anlamına gelir. Yalnızca BUILD dosyanızda test ettiğiniz alt modüllere bağlıysanız, tüm TensorFlow geliştiricileri için zamandan ve çok sayıda değerli hesaplama gücünden tasarruf edersiniz.
Bununla birlikte, derleme bağımlılığınızı tam TF hedeflerini atlayacak şekilde değiştirmek, Python kodunuzda içeri aktarabilecekleriniz için bazı sınırlamalar getirir. import tensorflow as tf artık birim testlerinizde import tensorflow as tf ifadesi import tensorflow as tf kullanamayacaksınız. Ancak bu, tüm geliştiricileri binlerce gereksiz test yapmaktan kurtardığı için değerli bir değiş tokuş.
Tüm kodun birim testleri olmalıdır
Yazdığınız herhangi bir kod için birim testlerini de yazmalısınız. Yeni bir foo.py dosyası foo.py , birim testlerini foo_test.py içine yerleştirmeli ve aynı değişiklikle göndermelisiniz. Tüm kodunuz için>% 90 artımlı test kapsamını hedefleyin.
TF'de yerel bazel testi kurallarını kullanmaktan kaçının
TF, testleri çalıştırırken birçok inceliğe sahiptir. Tüm bu karmaşıklıkları bazel makrolarımızda gizlemek için çalıştık. Bunlarla uğraşmak zorunda kalmamak için yerel test kuralları yerine aşağıdakileri kullanın. Tüm bunların tensorflow/tensorflow.bzl tanımlandığını tensorflow/tensorflow.bzl . CC testleri için tf_cc_test , tf_gpu_cc_test , tf_gpu_only_cc_test . Python testleri için tf_py_test veya gpu_py_test kullanın. Yerel py_test kuralına gerçekten yakın bir şeye ihtiyacınız varsa, lütfen bunun yerine tensorflow.bzl'de tanımlı olanı kullanın. BUILD dosyasının en üstüne şu satırı eklemeniz yeterlidir: load(“tensorflow/tensorflow.bzl”, “py_test”)
Testin nerede yürütüldüğünün farkında olun
Bir test yazdığınızda, test bilgilerimiz testlerinizi uygun şekilde yazarsanız CPU, GPU ve hızlandırıcılar üzerinde çalıştırabilir. GPU'lu veya GPU'suz sistemlere sahip Linux, macOS, pencereler üzerinde çalışan otomatik testlerimiz var. Yukarıda listelenen makrolardan birini seçmeniz ve ardından yürütüldükleri yeri sınırlamak için etiketleri kullanmanız yeterlidir.
manualetiket, testinizin herhangi bir yerde çalışmasını engelleyecektir. Bu,bazel test tensorflow/…gibi kalıpları kullanan manuel test yürütmelerini içerirbazel test tensorflow/…no_oss, testinizin resmi TF OSS test altyapısında çalışmasını engelleyecektir.no_macveyano_windowsetiketleri, testinizi ilgili işletim sistemi test paketlerinden çıkarmak için kullanılabilir.no_gpuetiketi, testinizin GPU test paketlerinde çalışmasını engellemek için kullanılabilir.
Testlerin beklenen test paketlerinde çalıştırıldığını doğrulayın
TF'nin epeyce test odası var. Bazen kurulum yapmak kafa karıştırıcı olabilir. Testlerinizin sürekli yapılardan çıkarılmasına neden olan farklı sorunlar olabilir. Bu nedenle, testlerinizin beklendiği gibi yürütüldüğünü doğrulamalısınız. Bunu yapmak için:
- Çekme İsteğinizdeki (PR) ön gönderimlerinizin tamamlanana kadar çalışmasını bekleyin.
- Durum kontrollerini görmek için PR'nizin alt kısmına gidin.
- Herhangi bir Kokoro çekinin sağ tarafındaki "Ayrıntılar" bağlantısını tıklayın.
- Yeni eklediğiniz hedefleri bulmak için "Hedefler" listesini kontrol edin.
Her sınıf / birimin kendi birim test dosyası olmalıdır
Ayrı test sınıfları, hataları ve kaynakları daha iyi izole etmemize yardımcı olur. Test dosyalarının çok daha kısa ve daha kolay okunmasına yol açarlar. Bu nedenle, tüm Python dosyalarınız en az bir karşılık gelen test dosyasına sahip olmalıdır (Her foo.py için foo_test.py olmalıdır). Farklı kurulumlar gerektiren entegrasyon testleri gibi daha ayrıntılı testler için daha fazla test dosyası eklemekte sorun yoktur.
Hız ve çalışma süreleri
Parçalama mümkün olduğunca az kullanılmalıdır
Parçalamak yerine lütfen şunları göz önünde bulundurun:
- Testlerinizi küçültmek
- Yukarıdakiler mümkün değilse, testleri bölün.
Parçalama, bir testin genel gecikmesini azaltmaya yardımcı olur, ancak aynı şey testleri daha küçük hedeflere bölerek de elde edilebilir. Bölme testleri bize her testte daha iyi bir kontrol seviyesi sağlar, gereksiz ön gönderme çalışmalarını en aza indirir ve hatalı çalışan bir test olayı nedeniyle tüm hedefi devre dışı bırakan bir buildcop kaynaklı kapsam kaybını azaltır. Ayrıca, parçalama, tüm parçalar için tüm test başlatma kodunu çalıştırmak gibi çok açık olmayan gizli maliyetlere neden olur. Bu sorun, ekstra yük yaratan bir kaynak olarak infra ekipleri tarafından bize iletildi.
Daha küçük testler daha iyidir
Testleriniz ne kadar hızlı yapılırsa, insanların testlerinizi yapma olasılığı o kadar artar. Testiniz için fazladan bir saniye, geliştiriciler ve altyapımız tarafından testinizi çalıştırmak için harcanan ekstra saatlere kadar birikebilir. Testlerinizi 30 saniyenin altında (isteğe bağlı olmayan modda!) Çalıştırmaya çalışın ve onları küçültün. Testlerinizi yalnızca son çare olarak orta olarak işaretleyin. Infra, ön sunumlar veya post-postalar olarak herhangi bir büyük test yürütmez! Bu nedenle, yalnızca nerede çalışacağını ayarlayacaksanız büyük bir test yazın. Testlerin daha hızlı çalışması için bazı ipuçları:
- Testinizde daha az eğitim yinelemesi çalıştırın
- Test edilen sistemin ağır bağımlılıklarını basit sahtelerle değiştirmek için bağımlılık enjeksiyonu kullanmayı düşünün.
- Birim testlerinde daha küçük girdi verileri kullanmayı düşünün
- Başka hiçbir şey işe yaramazsa, test dosyanızı bölmeyi deneyin.
Pulları önlemek için test süreleri, test boyutu zaman aşımının yarısını hedeflemelidir
bazel test hedeflerinde, küçük testlerin 1 dakikalık zaman aşımı vardır. Orta test zaman aşımları 5 dakikadır. Büyük testler sadece TensorFlow test infra tarafından yürütülmez. Bununla birlikte, birçok test, aldıkları süre bakımından belirleyici değildir. Çeşitli nedenlerden dolayı testleriniz ara sıra daha fazla zaman alabilir. Ve ortalama 50 saniye çalışan bir testi küçük olarak işaretlerseniz, testiniz eski CPU'lu bir makinede programlanırsa pul pul olacaktır. Bu nedenle, küçük testler için ortalama 30 saniyelik çalışma süresini hedefleyin. Orta düzey testler için 2 dakika 30 saniye ortalama çalışma süresi hedefleyin.
Numune sayısını azaltın ve eğitim toleranslarını artırın
Yavaş çalışan testler katkıda bulunanları caydırır. Testlerde antrenman yapmak çok yavaş olabilir. Testlerinizi yeterince hızlı tutmak için testlerinizde daha az numune kullanabilmek için daha yüksek toleransları tercih edin (maks. 2,5 dakika).
Belirsizliği ve pulları ortadan kaldırın
Belirleyici testler yazın
Birim testleri her zaman belirleyici olmalıdır. TAP ve gitarda çalışan tüm testler, onları etkileyen herhangi bir kod değişikliği yoksa, her seferinde aynı şekilde çalışmalıdır. Bunu sağlamak için, aşağıda dikkate alınması gereken bazı noktalar verilmiştir.
Her zaman stokastisite kaynağını tohumlayın
Herhangi bir rasgele sayı üreteci veya diğer herhangi bir stokastisite kaynağı, belirsizliğe neden olabilir. Bu nedenle, bunların her birinin tohumlanması gerekir. Testleri daha az kesintili yapmanın yanı sıra, bu, tüm testleri tekrarlanabilir hale getirir. TF testlerinde ayarlamanız gerekebilecek bazı tohumları belirlemenin farklı yolları şunlardır:
# 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)
Çok iş parçacıklı testlerde sleep kullanmaktan kaçının
Testlerde sleep fonksiyonunun kullanılması, pul pul olmanın önemli bir nedeni olabilir. Özellikle birden fazla iş parçacığı kullanırken, başka bir iş parçacığını beklemek için uyku modunu kullanmak asla belirleyici olmayacaktır. Bunun nedeni, sistemin farklı iş parçacıkları veya işlemlerin yürütülmesini herhangi bir şekilde garanti edememesidir. Bu nedenle, muteksler gibi deterministik senkronizasyon yapılarını tercih edin.
Testin kesintili olup olmadığını kontrol edin
Pullar, buildcops ve geliştiricilerin saatler kaybetmesine neden olur. Algılanmaları ve hata ayıklamaları zordur. Kesintileri tespit etmek için otomatik sistemler olsa da, testleri doğru bir şekilde geçersiz kılmak için yüzlerce test çalışması biriktirmeleri gerekir. Tespit ettiklerinde bile, testlerinizi geçersiz kılarlar ve test kapsamı kaybolur. Bu nedenle, test yazarları, testleri yazarken testlerinin başarısız olup olmadığını kontrol etmelidir. Bu, testinizi şu bayrakla çalıştırarak kolayca yapılabilir: --runs_per_test=1000
TensorFlowTestCase kullanın
TensorFlowTestCase, pürüzlülüğü olabildiğince azaltmak için kullanılan tüm rastgele sayı üreteçlerinin tohumlanması gibi gerekli önlemleri alır. Daha fazla kesinti kaynağı keşfedip düzelttikçe, bunların tümü TensorFlowTestCase'e eklenecektir. Bu nedenle, tensorflow için testler yazarken TensorFlowTestCase kullanmalısınız. TensorFlowTestCase burada tanımlanır: tensorflow/python/framework/test_util.py
Hermetik testler yazın
Hermetik testler herhangi bir dış kaynağa ihtiyaç duymaz. İhtiyaç duydukları her şeyle doludurlar ve ihtiyaç duyabilecekleri sahte hizmetlere başlarlar. Testleriniz dışındaki tüm hizmetler, determinizm olmamanın kaynağıdır. Diğer hizmetlerin% 99 kullanılabilirliği olsa bile, ağda flake olabilir, rpc yanıtı gecikebilir ve açıklanamaz bir hata mesajıyla sonuçlanabilir. Dış hizmetler GCS, S3 veya herhangi bir web sitesi olabilir, ancak bunlarla sınırlı değildir.