Nếu bạn đang viết thư viện hoặc ứng dụng, các tệp kiểm tra đơn vị sẽ đi đâu?

Thật tốt khi tách các tệp kiểm tra khỏi mã ứng dụng chính, nhưng thật khó để đặt chúng vào thư mục con "kiểm tra" bên trong thư mục gốc của ứng dụng, vì việc nhập các mô-đun mà bạn sẽ kiểm tra sẽ khó khăn hơn.

Có một thực hành tốt nhất ở đây?

Đối với một tệp module.py, kiểm tra đơn vị thường được gọi test_module.py, theo các quy ước đặt tên Pythonic.

Có một số nơi thường được chấp nhận để đặt test_module.py:

1. Trong cùng thư mục với module.py.
2. Trong ../tests/test_module.py(cùng cấp với thư mục mã).
3. Trong tests/test_module.py(một cấp dưới thư mục mã).

Tôi thích # 1 vì đơn giản trong việc tìm kiếm các bài kiểm tra và nhập chúng. Bất cứ hệ thống xây dựng nào bạn đang sử dụng đều có thể dễ dàng được cấu hình để chạy các tệp bắt đầu bằng test_. Trên thực tế, mẫu mặc định unittestđược sử dụng để khám phá thử nghiệm làtest*.py .

Chỉ có 1 tệp kiểm tra

Nếu chỉ có 1 tệp kiểm tra, nên đặt nó vào thư mục cấp cao nhất:

module/
    lib/
        __init__.py
        module.py
    test.py

Chạy thử nghiệm trong CLI

python test.py

Nhiều tập tin kiểm tra

Nếu có nhiều tệp kiểm tra, hãy đặt nó vào một teststhư mục:

module/
    lib/
        __init__.py
        module.py
    tests/
        test_module.py
        test_module_function.py

# test_module.py

import unittest
from lib import module

class TestModule(unittest.TestCase):
    def test_module(self):
        pass

if __name__ == '__main__':
    unittest.main()

Chạy thử nghiệm trong CLI

# In top-level /module/ folder
python -m tests.test_module
python -m tests.test_module_function

Sử dụng unittest discovery

unittest discovery sẽ tìm thấy tất cả các bài kiểm tra trong thư mục gói.

Tạo một __init__.pytrong tests/thư mục

module/
    lib/
        __init__.py
        module.py
    tests/
        __init__.py
        test_module.py
        test_module_function.py

Chạy thử nghiệm trong CLI

# In top-level /module/ folder

# -s, --start-directory (default current directory)
# -p, --pattern (default test*.py)

python -m unittest discover

Tài liệu tham khảo

• pytestThực hành tốt cho bố trí thử nghiệm
• unittest

Khung kiểm tra đơn vị

• mũi
• mũi2
• tế bào

Một thực tế phổ biến là đặt thư mục tests trong cùng thư mục cha với mô-đun / gói của bạn. Vì vậy, nếu mô-đun của bạn được gọi là foo.py bố cục thư mục của bạn sẽ như sau:

parent_dir/
  foo.py
  tests/

Tất nhiên không có cách nào để làm điều đó. Bạn cũng có thể tạo thư mục con kiểm tra và nhập mô-đun bằng cách nhập tuyệt đối .

Bất cứ nơi nào bạn đặt bài kiểm tra của mình, tôi sẽ khuyên bạn nên sử dụng mũi để chạy chúng. Mũi tìm kiếm thông qua các thư mục của bạn để kiểm tra. Bằng cách này, bạn có thể đặt các bài kiểm tra bất cứ nơi nào chúng có ý nghĩa nhất về mặt tổ chức.

Chúng tôi đã có cùng một câu hỏi khi viết Pythoscope ( https://pypi.org/project/pythcop/ ), trong đó tạo ra các bài kiểm tra đơn vị cho các chương trình Python. Chúng tôi đã thăm dò ý kiến ​​mọi người về thử nghiệm trong danh sách python trước khi chúng tôi chọn một thư mục, có nhiều ý kiến ​​khác nhau. Cuối cùng, chúng tôi đã chọn đặt một thư mục "tests" trong cùng thư mục với mã nguồn. Trong thư mục đó, chúng tôi tạo một tệp thử nghiệm cho mỗi mô-đun trong thư mục mẹ.

Tôi cũng có xu hướng đặt các bài kiểm tra đơn vị của mình vào tệp, như Jeremy Cantrell ở trên ghi chú, mặc dù tôi có xu hướng không đặt chức năng kiểm tra trong phần chính, mà thay vào đó đặt mọi thứ vào một

if __name__ == '__main__':
   do tests...

khối. Điều này kết thúc việc thêm tài liệu vào tệp dưới dạng 'mã ví dụ' để biết cách sử dụng tệp python mà bạn đang kiểm tra.

Tôi nên thêm, tôi có xu hướng viết các mô-đun / lớp rất chặt chẽ. Nếu các mô-đun của bạn yêu cầu số lượng thử nghiệm rất lớn, bạn có thể đặt chúng vào một thử nghiệm khác, nhưng ngay cả khi đó, tôi vẫn thêm:

if __name__ == '__main__':
   import tests.thisModule
   tests.thisModule.runtests

Điều này cho phép bất cứ ai đọc mã nguồn của bạn biết nơi để tìm mã kiểm tra.

Thỉnh thoảng tôi thấy mình kiểm tra chủ đề của vị trí kiểm tra và mỗi lần đa số đề xuất một cấu trúc thư mục riêng bên cạnh mã thư viện, nhưng tôi thấy rằng mỗi lần các đối số đều giống nhau và không thuyết phục. Tôi cuối cùng đặt các mô-đun thử nghiệm của tôi ở đâu đó bên cạnh các mô-đun cốt lõi.

Lý do chính để làm điều này là: tái cấu trúc .

Khi tôi di chuyển mọi thứ xung quanh tôi muốn các mô-đun thử nghiệm di chuyển với mã; thật dễ dàng để mất các bài kiểm tra nếu chúng ở trong một cây riêng biệt. Hãy trung thực, sớm hay muộn bạn kết thúc với một cấu trúc thư mục hoàn toàn khác, như django , bình và nhiều thứ khác. Sẽ tốt thôi nếu bạn không quan tâm.

Câu hỏi chính bạn nên tự hỏi mình là:

Tôi đang viết:

• a) thư viện tái sử dụng hoặc
• b) xây dựng một dự án hơn các gói cùng nhau một số mô-đun bán tách?

Nếu một:

Một thư mục riêng và nỗ lực thêm để duy trì cấu trúc của nó có thể phù hợp hơn. Không ai sẽ phàn nàn về các thử nghiệm của bạn được triển khai để sản xuất .

Nhưng thật dễ dàng để loại trừ các bài kiểm tra khỏi bị phân phối khi chúng được trộn với các thư mục cốt lõi; đặt cái này trong setup.py :

find_packages("src", exclude=["*.tests", "*.tests.*", "tests.*", "tests"]) 

Nếu b:

Bạn có thể muốn - như mọi người trong chúng ta làm - rằng bạn đang viết thư viện có thể sử dụng lại, nhưng phần lớn thời gian cuộc sống của họ gắn liền với cuộc sống của dự án. Khả năng dễ dàng duy trì dự án của bạn nên được ưu tiên.

Sau đó, nếu bạn đã làm một công việc tốt và mô-đun của bạn phù hợp với dự án khác, nó có thể sẽ được sao chép - không bị rẽ nhánh hoặc được tạo thành một thư viện riêng - vào dự án mới này và di chuyển các thử nghiệm nằm bên cạnh nó trong cùng cấu trúc thư mục thật dễ dàng so với việc kiểm tra các bài kiểm tra trong một mớ hỗn độn mà một thư mục kiểm tra riêng biệt đã trở thành. (Bạn có thể lập luận rằng nó không nên là một mớ hỗn độn ở nơi đầu tiên nhưng hãy thực tế ở đây).

Vì vậy, sự lựa chọn vẫn là của bạn, nhưng tôi sẽ lập luận rằng với các bài kiểm tra hỗn hợp, bạn đạt được tất cả những điều tương tự như với một thư mục riêng, nhưng ít nỗ lực hơn trong việc giữ mọi thứ gọn gàng.

Tôi sử dụng một tests/thư mục, và sau đó nhập các mô-đun ứng dụng chính bằng cách nhập tương đối. Vì vậy, trong MyApp / tests / foo.py, có thể có:

from .. import foo

để nhập MyApp.foomô-đun.

Tôi không tin rằng có một "thực tiễn tốt nhất" được thiết lập.

Tôi đặt các bài kiểm tra của mình trong một thư mục khác bên ngoài mã ứng dụng. Sau đó tôi thêm thư mục ứng dụng chính vào sys.path (cho phép bạn nhập các mô-đun từ bất cứ đâu) trong tập lệnh chạy thử nghiệm của tôi (cũng thực hiện một số nội dung khác) trước khi chạy tất cả các bài kiểm tra. Bằng cách này, tôi không bao giờ phải xóa thư mục kiểm tra khỏi mã chính khi tôi phát hành nó, tiết kiệm thời gian và công sức của tôi, nếu một số tiền rất nhỏ.

Từ kinh nghiệm của tôi trong việc phát triển các khung Kiểm tra trong Python, tôi sẽ đề nghị đặt các bài kiểm tra đơn vị python vào một thư mục riêng. Duy trì cấu trúc thư mục đối xứng. Điều này sẽ hữu ích trong việc đóng gói chỉ các thư viện cốt lõi và không đóng gói các bài kiểm tra đơn vị. Dưới đây được thực hiện thông qua một sơ đồ.

                              <Main Package>
                               /          \
                              /            \
                            lib           tests
                            /                \
             [module1.py, module2.py,  [ut_module1.py, ut_module2.py,
              module3.py  module4.py,   ut_module3.py, ut_module.py]
              __init__.py]

Theo cách này khi bạn đóng gói các thư viện này bằng vòng / phút, bạn chỉ có thể đóng gói các mô-đun thư viện chính (chỉ). Điều này giúp duy trì đặc biệt trong môi trường nhanh nhẹn.

Tôi khuyên bạn nên kiểm tra một số dự án Python chính trên GitHub và lấy một số ý tưởng.

Khi mã của bạn lớn hơn và bạn thêm nhiều thư viện, tốt hơn là tạo một thư mục thử nghiệm trong cùng thư mục mà bạn có setup.py và phản ánh cấu trúc thư mục dự án của bạn cho từng loại thử nghiệm (không tích hợp, tích hợp, ...)

Ví dụ: nếu bạn có cấu trúc thư mục như:

myPackage/
    myapp/
       moduleA/
          __init__.py
          module_A.py
       moduleB/
          __init__.py
          module_B.py
setup.py

Sau khi thêm thư mục kiểm tra, bạn sẽ có một cấu trúc thư mục như:

myPackage/
    myapp/
       moduleA/
          __init__.py
          module_A.py
       moduleB/
          __init__.py
          module_B.py
test/
   unit/
      myapp/
         moduleA/
            module_A_test.py
         moduleB/
            module_B_test.py
   integration/
          myapp/
             moduleA/
                module_A_test.py
             moduleB/
                module_B_test.py
setup.py

Nhiều gói Python được viết đúng sử dụng cùng một cấu trúc. Một ví dụ rất hay là gói Boto. Kiểm tra https://github.com/boto/boto

Làm thế nào tôi làm điều đó...

Cấu trúc thư mục:

project/
    src/
        code.py
    tests/
    setup.py

Setup.py trỏ đến src / là vị trí chứa các mô đun dự án của tôi, sau đó tôi chạy:

setup.py develop

Mà thêm dự án của tôi vào các gói trang web, chỉ vào bản sao làm việc của tôi. Để chạy thử nghiệm của tôi, tôi sử dụng:

setup.py tests

Sử dụng bất kỳ trình chạy thử nào tôi đã cấu hình.

Tôi thích thư mục kiểm tra toplevel. Điều này không có nghĩa là nhập khẩu trở nên khó khăn hơn một chút. Cho rằng tôi có hai giải pháp:

1. Sử dụng setuptools. Sau đó bạn có thể vượt quatest_suite='tests.runalltests.suite' thành setup(), và có thể chạy các bài kiểm tra đơn giản:python setup.py test
2. Đặt PYTHONPATH khi chạy thử nghiệm: PYTHONPATH=. python tests/runalltests.py

Đây là cách những thứ đó được hỗ trợ bởi mã trong M2Crypto:

• http://svn.osafoundation.org/m2crypto/trunk/setup.py
• http://svn.osafoundation.org/m2crypto/trunk/tests/alltests.py

Nếu bạn thích chạy thử nghiệm với nosetests, bạn có thể cần phải làm một cái gì đó hơi khác một chút.

Chúng tôi sử dụng

app/src/code.py
app/testing/code_test.py 
app/docs/..

Trong mỗi tệp thử nghiệm, chúng tôi chèn ../src/vào sys.path. Đây không phải là giải pháp tốt nhất nhưng hiệu quả. Tôi nghĩ sẽ thật tuyệt nếu ai đó nghĩ ra một thứ như maven trong java cung cấp cho bạn các quy ước tiêu chuẩn chỉ hoạt động, bất kể bạn làm việc trên dự án nào.

Nếu các bài kiểm tra đơn giản, chỉ cần đặt chúng vào chuỗi doc - hầu hết các khung kiểm tra cho Python sẽ có thể sử dụng:

>>> import module
>>> module.method('test')
'testresult'

Đối với các thử nghiệm liên quan khác, tôi sẽ đặt chúng vào ../tests/test_module.pyhoặc vào tests/test_module.py.

Trong C #, tôi thường tách các thử nghiệm thành một cụm riêng biệt.

Trong Python - cho đến nay - tôi đã có xu hướng viết các tài liệu, trong đó bài kiểm tra nằm trong chuỗi tài liệu của hàm hoặc đặt chúng vào if __name__ == "__main__"khối ở dưới cùng của mô-đun.

Khi viết một gói có tên là "foo", tôi sẽ đặt các bài kiểm tra đơn vị vào một gói riêng "foo_test". Các mô-đun và gói con sau đó sẽ có cùng tên với mô-đun gói SUT. Ví dụ: các kiểm tra cho một mô-đun foo.xy được tìm thấy trong foo_test.xy Các tệp __init__.py của mỗi gói kiểm tra sau đó chứa bộ AllTests bao gồm tất cả các bộ kiểm tra của gói. setuptools cung cấp một cách thuận tiện để chỉ định gói thử nghiệm chính, để sau khi "python setup.py phát triển", bạn có thể sử dụng "python setup.py test" hoặc "python setup.py test -s foo_test.x.SomeTestSuite" cho chỉ là một bộ cụ thể.

Tôi đặt các bài kiểm tra của mình trong cùng thư mục với mã được kiểm tra (CUT); cho foo.pycác bài kiểm tra sẽ trong foo_ut.pyhoặc tương tự. (Tôi điều chỉnh quá trình khám phá thử nghiệm để tìm những thứ này.)

Điều này đặt các bài kiểm tra ngay bên cạnh mã trong danh sách thư mục, làm rõ rằng các bài kiểm tra ở đó và giúp mở các bài kiểm tra dễ dàng nhất có thể khi chúng nằm trong một tệp riêng biệt. (Đối với người chỉnh sửa dòng lệnh,vim foo* và khi sử dụng trình duyệt hệ thống tệp đồ họa, chỉ cần nhấp vào tệp CUT và sau đó là tệp thử nghiệm liền kề.)

Như những người khác đã chỉ ra , điều này cũng làm cho việc tái cấu trúc dễ dàng hơn và trích xuất mã để sử dụng ở nơi khác nếu cần thiết.

Tôi thực sự không thích ý tưởng đưa các bài kiểm tra vào một cây thư mục hoàn toàn khác; tại sao làm cho các nhà phát triển khó mở các bài kiểm tra hơn khi họ mở tệp bằng CUT? Nó không giống như đại đa số các nhà phát triển rất thích viết hoặc tinh chỉnh các bài kiểm tra mà họ sẽ bỏ qua mọi rào cản để làm điều đó, thay vì sử dụng rào cản như một cái cớ. (Hoàn toàn ngược lại, theo kinh nghiệm của tôi; ngay cả khi bạn làm cho nó dễ dàng nhất có thể, tôi biết nhiều nhà phát triển không thể bận tâm để viết bài kiểm tra.)

Gần đây tôi đã bắt đầu lập trình bằng Python, vì vậy tôi chưa thực sự có cơ hội tìm hiểu thực tiễn tốt nhất. Nhưng, tôi đã viết một mô-đun đi và tìm tất cả các bài kiểm tra và chạy chúng.

Vì vậy, tôi có:

ứng dụng /
 appfile.py
kiểm tra/
 appfileTest.py

Tôi sẽ phải xem mọi thứ diễn ra như thế nào khi tôi tiến tới các dự án lớn hơn.