Liệu Python unittests có nằm trong một module riêng biệt không?

Question

Có sự đồng thuận nào về địa điểm tốt nhất để đặt các phần mềm không cần thiết của Python không?

Nếu các unittests được bao gồm trong cùng một mô-đun như chức năng đang được thử nghiệm (được thực thi khi mô-đun tự chạy (if __name__ == '__main__', v.v.)), hoặc tốt hơn để bao gồm các unittests trong các mô-đun khác nhau? Có lẽ một sự kết hợp của cả hai cách tiếp cận là tốt nhất, bao gồm kiểm tra mức mô-đun trong mỗi mô-đun và thêm các bài kiểm tra mức cao hơn mà chức năng kiểm tra được bao gồm trong nhiều hơn một mô-đun riêng biệt (có thể trong thư mục con/kiểm tra?).

Tôi cho rằng khám phá thử nghiệm đơn giản hơn nếu các thử nghiệm được bao gồm trong các mô-đun riêng biệt, nhưng có thêm gánh nặng cho nhà phát triển nếu người đó phải nhớ cập nhật mô-đun thử nghiệm bổ sung nếu mô-đun đang được kiểm tra được sửa đổi.

Tôi muốn được quan tâm để biết suy nghĩ của mọi người về cách tổ chức khai thác tốt nhất.

Answer 1

1. Trong trường hợp bạn phải nếu sử dụng một thư viện xác định nơi unittests nên sống,
2. trong module mình cho các dự án nhỏ, hoặc
3. trong thư mục con tests/ trong gói của bạn cho các dự án lớn hơn.

Đó là vấn đề về những gì hiệu quả nhất cho dự án bạn đang tạo.

Đôi khi các thư viện bạn đang sử dụng xác định nơi xét nghiệm nên đi, như là trường hợp với Django (nơi bạn đặt thử nghiệm của bạn trong models.py, tests.py hoặc một thư mục con tests/ trong các ứng dụng của bạn).

Nếu không có ràng buộc hiện tại, đó là vấn đề sở thích cá nhân. Đối với một nhóm nhỏ các mô-đun, có thể thuận tiện hơn khi đặt các unittests trong các tệp bạn đang tạo.

Đối với bất kỳ điều gì nhiều hơn một vài mô-đun, tôi tạo riêng các bài kiểm tra trong thư mục tests/ trong gói. Có mã thử nghiệm được trộn lẫn với việc triển khai thêm tiếng ồn không cần thiết cho bất kỳ ai đọc mã.

Answer 2

Cá nhân, tôi tạo một bài kiểm tra/thư mục trong thư mục nguồn và cố gắng, nhiều hơn hoặc ít hơn, phản chiếu phân cấp mã nguồn chính của tôi với các đơn vị kiểm tra đơn vị (có 1 mô-đun thử nghiệm 1 mô-đun đơn vị).

Lưu ý rằng tôi đang sử dụng nose và triết lý của nó hơi khác một chút so với không phân biệt.

Answer 3

Tôi thường giữ mã thử nghiệm trong một mô-đun riêng biệt và gửi mô-đun/gói và thử nghiệm trong một bản phân phối duy nhất. Nếu người dùng cài đặt bằng cách sử dụng setup.py họ có thể chạy thử nghiệm từ thư mục kiểm tra để đảm bảo rằng mọi thứ hoạt động trong môi trường của họ, nhưng chỉ mã của mô-đun kết thúc dưới Lib/site-packages.

Answer 4

if __name__ == '__main__', v.v. thật tuyệt vời cho các thử nghiệm nhỏ.

Answer 5

Có thể có các lý do khác ngoài thử nghiệm để sử dụng séc if __name__ == '__main__'. Giữ các bài kiểm tra trong các module khác để lại tùy chọn đó cho bạn. Ngoài ra - nếu bạn cấu trúc lại việc thực hiện một mô-đun và các thử nghiệm của bạn nằm trong một mô-đun khác không được chỉnh sửa - bạn BIẾT các thử nghiệm chưa được thay đổi khi bạn chạy chúng với mã được tái cấu trúc.

Answer 6

Tôi thường có chúng trong một thư mục riêng biệt được gọi là thường xuyên nhất kiểm tra/. Cá nhân tôi không sử dụng kiểm tra nếu __name__ == '__main__', bởi vì tôi sử dụng nosetests và nó xử lý phát hiện kiểm tra của chính nó.

Answer 7

CÓ, hãy sử dụng mô-đun riêng.

Không thực sự hợp lý khi sử dụng thủ thuật __main__. Chỉ cần giả sử rằng bạn có một số tệp trong mô-đun của mình và nó không hoạt động nữa, bởi vì bạn không muốn chạy từng tệp nguồn riêng biệt khi thử nghiệm mô-đun của mình.

Ngoài ra, khi cài đặt mô-đun, phần lớn thời gian bạn không muốn cài đặt các thử nghiệm. Người dùng cuối của bạn không quan tâm đến các bài kiểm tra, chỉ các nhà phát triển nên quan tâm.

Không, thực sự. Đặt các bài kiểm tra của bạn vào tests/, tài liệu của bạn ở doc và có một Makefile sẵn sàng xung quanh cho một make test. Bất kỳ phương pháp tiếp cận nào khác chỉ là các giải pháp trung gian, chỉ có giá trị đối với các mô-đun nhỏ cụ thể.