Đây là các phương pháp được khuyến nghị để kiểm tra mã trong kho lưu trữ TensorFlow .
Trước khi bạn bắt đầu
Trước khi bạn đóng góp mã nguồn cho dự án TensorFlow, vui lòng xem lại tệp CONTRIBUTING.md trong repo GitHub của dự án. (Ví dụ: xem tệp CONTRIBUTING.md cho đại diện TensorFlow cốt lõi .) Tất cả những người đóng góp mã được yêu cầu ký Thỏa thuận cấp phép cộng tác viên (CLA).
Nguyên tắc chung
Chỉ phụ thuộc vào những gì bạn sử dụng trong quy tắc BUILD của mình
TensorFlow là một thư viện lớn và phụ thuộc vào gói đầy đủ khi viết một bài kiểm tra đơn vị cho các mô-đun con của nó là một thực tế phổ biến. Tuy nhiên, điều này vô hiệu hóa phân tích dựa trên sự phụ thuộc bazel . Điều này có nghĩa là các hệ thống tích hợp liên tục không thể loại bỏ một cách thông minh các bài kiểm tra không liên quan đối với các lần gửi trước / gửi sau. Nếu bạn chỉ phụ thuộc vào các mô-đun con mà bạn đang thử nghiệm trong tệp BUILD của mình, bạn sẽ tiết kiệm thời gian cho tất cả các nhà phát triển TensorFlow và rất nhiều sức mạnh tính toán có giá trị.
Tuy nhiên, việc sửa đổi phụ thuộc xây dựng của bạn để bỏ qua các mục tiêu TF đầy đủ mang lại một số hạn chế cho những gì bạn có thể nhập trong mã Python của mình. Bạn sẽ không thể sử dụng lệnh import tensorflow as tf trong các bài kiểm tra đơn vị của mình nữa. Nhưng đây là một sự đánh đổi đáng giá vì nó giúp tất cả các nhà phát triển không phải chạy hàng nghìn bài kiểm tra không cần thiết.
Tất cả mã phải có bài kiểm tra đơn vị
Đối với bất kỳ mã nào bạn viết, bạn cũng nên viết các bài kiểm tra đơn vị của nó. Nếu bạn viết một tệp mới foo.py , bạn nên đặt các bài kiểm tra đơn vị của nó trong foo_test.py và gửi nó trong cùng một thay đổi. Nhắm đến phạm vi kiểm tra gia tăng> 90% cho tất cả mã của bạn.
Tránh sử dụng các quy tắc kiểm tra bazel gốc trong TF
TF có rất nhiều sự tinh tế khi chạy thử nghiệm. Chúng tôi đã làm việc để ẩn tất cả những phức tạp đó trong các macro bazel của chúng tôi. Để tránh phải đối phó với những điều đó, hãy sử dụng các quy tắc sau thay vì các quy tắc kiểm tra gốc. Lưu ý rằng tất cả những điều này được định nghĩa trong tensorflow/tensorflow.bzl Đối với các bài kiểm tra CC, hãy sử dụng tf_cc_test , tf_gpu_cc_test , tf_gpu_only_cc_test . Đối với các bài kiểm tra python, hãy sử dụng tf_py_test hoặc gpu_py_test . Nếu bạn cần thứ gì đó thực sự gần với quy tắc py_test gốc, hãy sử dụng quy tắc được xác định trong tensorflow.bzl thay thế. Bạn chỉ cần thêm dòng sau vào đầu tệp BUILD: load(“tensorflow/tensorflow.bzl”, “py_test”)
Nhận biết nơi thực thi thử nghiệm
Khi bạn viết một bài kiểm tra, cơ sở hạ tầng kiểm tra của chúng tôi có thể đảm nhận việc chạy các bài kiểm tra của bạn trên CPU, GPU và bộ tăng tốc nếu bạn viết chúng cho phù hợp. Chúng tôi có các bài kiểm tra tự động chạy trên Linux, macos, windows, những hệ thống có hoặc không có GPU. Bạn chỉ cần chọn một trong các macro được liệt kê ở trên, sau đó sử dụng các thẻ để giới hạn nơi chúng được thực thi.
manualthẻ sẽ loại trừ thử nghiệm của bạn từ bất cứ nơi nào chạy. Điều này bao gồm thực hiện kiểm tra thủ công sử dụng các mẫu nhưbazel test tensorflow/…no_osssẽ loại trừ thử nghiệm của bạn chạy trong cơ sở hạ tầng thử nghiệm TF OSS chính thức.no_machoặcno_windowscó thể được sử dụng để loại trừ thử nghiệm của bạn khỏi các bộ thử nghiệm hệ điều hành có liên quan.Thẻ
no_gpucó thể được sử dụng để loại trừ thử nghiệm của bạn chạy trong các bộ thử nghiệm GPU.
Xác minh các thử nghiệm chạy trong các bộ thử nghiệm dự kiến
TF có khá nhiều dãy phòng thử nghiệm. Đôi khi, chúng có thể gây nhầm lẫn khi thiết lập. Có thể có các vấn đề khác nhau khiến các thử nghiệm của bạn bị bỏ qua khỏi các bản dựng liên tục. Do đó, bạn nên xác minh rằng các thử nghiệm của bạn đang thực hiện như mong đợi. Để làm điều này:
- Chờ các bản gửi trước trong Yêu cầu kéo (PR) của bạn chạy đến khi hoàn thành.
- Cuộn xuống cuối PR của bạn để xem các kiểm tra trạng thái.
- Nhấp vào liên kết "Chi tiết" ở phía bên phải của bất kỳ kiểm tra Kokoro nào.
- Kiểm tra danh sách "Mục tiêu" để tìm các mục tiêu mới được thêm vào của bạn.
Mỗi lớp / đơn vị phải có tệp kiểm tra đơn vị riêng của nó
Các lớp kiểm tra riêng biệt giúp chúng tôi cô lập tốt hơn các lỗi và tài nguyên. Chúng dẫn đến các tệp thử nghiệm ngắn hơn và dễ đọc hơn nhiều. Do đó, tất cả các tệp Python của bạn phải có ít nhất một tệp thử nghiệm tương ứng (Đối với mỗi foo.py , nó phải có foo_test.py ). Đối với các bài kiểm tra phức tạp hơn, chẳng hạn như các bài kiểm tra tích hợp yêu cầu các thiết lập khác nhau, bạn có thể thêm nhiều tệp kiểm tra hơn.
Tốc độ và thời gian chạy
Sharding nên được sử dụng càng ít càng tốt
Thay vì sharding, vui lòng xem xét:
- Làm cho các thử nghiệm của bạn nhỏ hơn
- Nếu những điều trên không thực hiện được, hãy chia nhỏ các bài kiểm tra ra
Sharding giúp giảm độ trễ tổng thể của một bài kiểm tra, nhưng điều tương tự cũng có thể đạt được bằng cách chia nhỏ các bài kiểm tra thành các mục tiêu nhỏ hơn. Việc phân tách các bài kiểm tra mang lại cho chúng tôi mức độ kiểm soát tốt hơn trên mỗi bài kiểm tra, giảm thiểu các lần chạy gửi trước không cần thiết và giảm tổn thất vùng phủ sóng từ việc bản dựng làm vô hiệu hóa toàn bộ mục tiêu do hộp kiểm hoạt động sai. Hơn nữa, sharding phải chịu các chi phí ẩn không quá rõ ràng, chẳng hạn như chạy tất cả mã khởi tạo thử nghiệm cho tất cả các phân đoạn. Vấn đề này đã được chúng tôi báo cáo bởi các nhóm hạ tầng như một nguồn tạo ra thêm tải.
Các bài kiểm tra nhỏ hơn sẽ tốt hơn
Các bài kiểm tra của bạn chạy càng nhanh, thì càng có nhiều khả năng mọi người chạy các bài kiểm tra của bạn. Thêm một giây cho bài kiểm tra của bạn có thể tích lũy thêm hàng giờ dành cho việc chạy bài kiểm tra của các nhà phát triển và cơ sở hạ tầng của chúng tôi. Cố gắng làm cho các bài kiểm tra của bạn chạy dưới 30 giây (ở chế độ không chọn!) Và thu nhỏ chúng. Chỉ đánh dấu các bài kiểm tra của bạn là phương tiện cuối cùng. Cơ sở hạ tầng không chạy bất kỳ thử nghiệm lớn nào dưới dạng gửi trước hoặc gửi sau! Do đó, chỉ nên viết một bài kiểm tra lớn nếu bạn sắp xếp nơi nó sẽ chạy. Một số mẹo để làm cho các bài kiểm tra chạy nhanh hơn:
- Chạy ít lần lặp lại đào tạo hơn trong bài kiểm tra của bạn
- Cân nhắc sử dụng phương pháp tiêm phụ thuộc để thay thế các phụ thuộc nặng nề của hệ thống đang thử nghiệm bằng các lỗi đơn giản.
- Cân nhắc sử dụng dữ liệu đầu vào nhỏ hơn trong các bài kiểm tra đơn vị
- Nếu không có gì khác hoạt động, hãy thử chia nhỏ tệp thử nghiệm của bạn.
Thời gian thử nghiệm nên dành cho một nửa thời gian chờ của kích thước thử nghiệm để tránh bong tróc
Với các mục tiêu kiểm tra bazel , các bài kiểm tra nhỏ có thời gian chờ 1 phút. Thời gian chờ của bài kiểm tra trung bình là 5 phút. Các bài kiểm tra lớn không được thực hiện bởi cơ sở hạ tầng kiểm tra TensorFlow. Tuy nhiên, nhiều bài kiểm tra không xác định được lượng thời gian mà chúng thực hiện. Vì nhiều lý do khác nhau, thỉnh thoảng, các bài kiểm tra của bạn có thể mất nhiều thời gian hơn. Và, nếu bạn đánh dấu một bài kiểm tra chạy trung bình trong 50 giây là nhỏ, thì bài kiểm tra của bạn sẽ bị lỗi nếu nó lên lịch trên một máy có CPU cũ. Do đó, hãy đặt mục tiêu thời gian chạy trung bình 30 giây cho các bài kiểm tra nhỏ. Đặt mục tiêu thời gian chạy trung bình là 2 phút 30 giây cho các bài kiểm tra trung bình.
Giảm số lượng mẫu và tăng dung sai cho đào tạo
Các bài kiểm tra chạy chậm sẽ ngăn cản những người đóng góp. Chạy huấn luyện trong các bài kiểm tra có thể rất chậm. Thích dung sai cao hơn để có thể sử dụng ít mẫu hơn trong các thử nghiệm của bạn để giữ cho các thử nghiệm của bạn đủ nhanh (tối đa 2,5 phút).
Loại bỏ các yếu tố không xác định và mảnh
Viết các bài kiểm tra xác định
Các bài kiểm tra đơn vị phải luôn mang tính xác định. Tất cả các bài kiểm tra chạy trên TAP và guitar phải chạy theo cùng một cách mỗi lần, nếu không có thay đổi mã nào ảnh hưởng đến chúng. Để đảm bảo điều này, dưới đây là một số điểm cần xem xét.
Luôn gieo rắc bất kỳ nguồn ngẫu nhiên nào
Bất kỳ trình tạo số ngẫu nhiên nào hoặc bất kỳ nguồn ngẫu nhiên nào khác đều có thể gây ra hiện tượng không ổn định. Vì vậy, mỗi cái này phải được gieo hạt. Ngoài việc làm cho các bài kiểm tra ít bong tróc hơn, điều này còn làm cho tất cả các bài kiểm tra có thể tái tạo được. Các cách khác nhau để đặt một số hạt giống mà bạn có thể cần đặt trong thử nghiệm TF là:
# 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)
Tránh sử dụng sleep trong các bài kiểm tra đa luồng
Sử dụng chức năng sleep trong các bài kiểm tra có thể là nguyên nhân chính gây ra tình trạng bong tróc da. Đặc biệt là khi sử dụng nhiều luồng, sử dụng chế độ ngủ để chờ một luồng khác sẽ không bao giờ có tính xác định. Điều này là do hệ thống không thể đảm bảo bất kỳ thứ tự thực hiện các luồng hoặc quy trình khác nhau. Do đó, hãy thích các cấu trúc đồng bộ hóa xác định như mutexes.
Kiểm tra xem bài kiểm tra có bị bong không
Flakes gây ra các khối xây dựng và các nhà phát triển mất nhiều giờ. Chúng khó phát hiện và khó gỡ lỗi. Mặc dù có các hệ thống tự động để phát hiện lỗi, chúng cần phải tích lũy hàng trăm lần chạy thử trước khi có thể từ chối chính xác các bài kiểm tra trong danh sách. Ngay cả khi họ phát hiện, họ từ chối danh sách các thử nghiệm của bạn và phạm vi kiểm tra sẽ bị mất. Do đó, các tác giả bài kiểm tra nên kiểm tra xem bài kiểm tra của họ có bị bong khi viết bài kiểm tra hay không. Điều này có thể dễ dàng thực hiện bằng cách chạy thử nghiệm của bạn với cờ: --runs_per_test=1000
Sử dụng TensorFlowTestCase
TensorFlowTestCase thực hiện các biện pháp phòng ngừa cần thiết, chẳng hạn như gieo hạt tất cả các trình tạo số ngẫu nhiên được sử dụng để giảm hiện tượng bong tróc nhiều nhất có thể. Khi chúng tôi phát hiện và khắc phục nhiều nguồn không ổn định hơn, tất cả những nguồn này sẽ được thêm vào TensorFlowTestCase. Do đó, bạn nên sử dụng TensorFlowTestCase khi viết các bài kiểm tra cho tensorflow. TensorFlowTestCase được định nghĩa tại đây: tensorflow/python/framework/test_util.py
Viết các bài kiểm tra kín
Các bài kiểm tra Hermetic không cần bất kỳ nguồn lực bên ngoài nào. Họ được đóng gói với mọi thứ họ cần và họ chỉ bắt đầu bất kỳ dịch vụ giả mạo nào mà họ có thể cần. Bất kỳ dịch vụ nào khác với các thử nghiệm của bạn đều là nguồn không xác định. Ngay cả với 99% tính khả dụng của các dịch vụ khác, mạng có thể bị ngắt, phản hồi rpc có thể bị trì hoãn và bạn có thể nhận được thông báo lỗi không thể giải thích được. Các dịch vụ bên ngoài có thể là, nhưng không giới hạn, GCS, S3 hoặc bất kỳ trang web nào.