unittest --- Khung kiểm tra đơn vị

Source code: Lib/unittest/__init__.py

---

(Nếu bạn đã quen với các khái niệm cơ bản về thử nghiệm, bạn có thể muốn chuyển sang the list of assert methods.)

Khung thử nghiệm đơn vị unittest ban đầu được lấy cảm hứng từ JUnit và có hương vị tương tự như các khung thử nghiệm đơn vị chính trong các ngôn ngữ khác. Nó hỗ trợ tự động hóa thử nghiệm, chia sẻ mã thiết lập và tắt cho các thử nghiệm, tổng hợp các thử nghiệm thành các bộ sưu tập và tính độc lập của các thử nghiệm khỏi khung báo cáo.

Để đạt được điều này, unittest hỗ trợ một số khái niệm quan trọng theo cách hướng đối tượng:

vật cố định thử nghiệm

Zz000zz thể hiện sự chuẩn bị cần thiết để thực hiện một hoặc nhiều thử nghiệm và mọi hành động dọn dẹp liên quan. Điều này có thể liên quan đến việc tạo cơ sở dữ liệu, thư mục tạm thời hoặc proxy hoặc khởi động quy trình máy chủ.

trường hợp thử nghiệm

Zz000zz là đơn vị thử nghiệm riêng lẻ. Nó kiểm tra phản hồi cụ thể cho một bộ đầu vào cụ thể. unittest cung cấp một lớp cơ sở, TestCase, có thể được sử dụng để tạo các trường hợp thử nghiệm mới.

bộ thử nghiệm

Zz000zz là tập hợp các trường hợp thử nghiệm, bộ thử nghiệm hoặc cả hai. Nó được sử dụng để tổng hợp các bài kiểm tra cần được thực hiện cùng nhau.

người chạy thử

Zz000zz là thành phần điều phối việc thực hiện các thử nghiệm và cung cấp kết quả cho người dùng. Người chạy có thể sử dụng giao diện đồ họa, giao diện văn bản hoặc trả về một giá trị đặc biệt để cho biết kết quả thực hiện kiểm tra.

Xem thêm

Mô-đun doctest

Một mô-đun hỗ trợ thử nghiệm khác có hương vị rất khác.

Simple Smalltalk Testing: With Patterns

Bài viết gốc của Kent Beck về các khung thử nghiệm sử dụng mẫu được chia sẻ bởi unittest.

pytest

Khung đơn vị nhất của bên thứ ba với cú pháp nhẹ hơn để viết bài kiểm tra. Ví dụ: assert func(10) == 42.

The Python Testing Tools Taxonomy

Danh sách đầy đủ các công cụ kiểm tra Python bao gồm các khung kiểm tra chức năng và thư viện đối tượng mô phỏng.

Testing in Python Mailing List

Một nhóm quan tâm đặc biệt để thảo luận về thử nghiệm và các công cụ thử nghiệm bằng Python.

Tập lệnh Tools/unittestgui/unittestgui.py trong bản phân phối nguồn Python là một công cụ GUI để khám phá và thực thi thử nghiệm. Điều này chủ yếu nhằm mục đích dễ sử dụng cho những người mới thử nghiệm đơn vị. Đối với môi trường sản xuất, các thử nghiệm nên được điều khiển bởi hệ thống tích hợp liên tục, chẳng hạn như Buildbot, Jenkins, GitHub Actions hoặc AppVeyor.

Ví dụ cơ bản

Mô-đun unittest cung cấp một bộ công cụ phong phú để xây dựng và chạy thử nghiệm. Phần này chứng tỏ rằng một tập hợp nhỏ các công cụ này đủ để đáp ứng nhu cầu của hầu hết người dùng.

Đây là đoạn script ngắn để kiểm tra ba phương thức chuỗi:

nhập khẩu đơn vị nhất

lớp TestStringMethods(unittest.TestCase):

    def test_upper(tự):
        self.assertEqual('foo'.upper(), 'FOO')

    def test_isupper(tự):
        self.assertTrue('FOO'.isupper())
        self.assertFalse('Foo'.isupper())

    def test_split(tự):
        s = 'xin chào thế giới'
        self.assertEqual(s.split(), ['xin chào', 'thế giới'])
        # check rằng s.split bị lỗi khi dấu phân cách không phải là một chuỗi
        với self.assertRaises(TypeError):
            s.split(2)

nếu __name__ == '__main__':
    unittest.main()

Một trường hợp thử nghiệm được tạo bằng cách phân lớp unittest.TestCase. Ba thử nghiệm riêng lẻ được xác định bằng các phương thức có tên bắt đầu bằng các chữ cái test. Quy ước đặt tên này thông báo cho người chạy thử nghiệm về phương thức nào đại diện cho các thử nghiệm.

Điểm mấu chốt của mỗi bài kiểm tra là lệnh gọi tới assertEqual() để kiểm tra kết quả mong đợi; assertTrue() hoặc assertFalse() để xác minh một điều kiện; hoặc assertRaises() để xác minh rằng một ngoại lệ cụ thể sẽ được đưa ra. Các phương thức này được sử dụng thay cho câu lệnh assert để người chạy thử có thể tích lũy tất cả các kết quả thử nghiệm và tạo ra một báo cáo.

Phương thức setUp() và tearDown() cho phép bạn xác định các hướng dẫn sẽ được thực thi trước và sau mỗi phương thức kiểm tra. Chúng được đề cập chi tiết hơn trong phần Tổ chức mã kiểm tra.

Khối cuối cùng hiển thị cách đơn giản để chạy thử nghiệm. unittest.main() cung cấp giao diện dòng lệnh cho tập lệnh thử nghiệm. Khi chạy từ dòng lệnh, đoạn script trên tạo ra kết quả trông như thế này:

...
----------------------------------------------------------------------
Chạy 3 bài kiểm tra trong 0,000 giây

được rồi

Việc chuyển tùy chọn -v vào tập lệnh thử nghiệm của bạn sẽ hướng dẫn unittest.main() kích hoạt mức độ chi tiết cao hơn và tạo ra kết quả đầu ra sau:

test_isupper (__main__.TestStringMethods.test_isupper) ... được
test_split (__main__.TestStringMethods.test_split) ... được
test_upper (__main__.TestStringMethods.test_upper) ... được

----------------------------------------------------------------------
Chạy 3 bài kiểm tra trong 0,001 giây

được rồi

Các ví dụ trên cho thấy các tính năng unittest được sử dụng phổ biến nhất, đủ để đáp ứng nhiều nhu cầu thử nghiệm hàng ngày. Phần còn lại của tài liệu khám phá bộ tính năng đầy đủ từ các nguyên tắc đầu tiên.

Thay đổi trong phiên bản 3.11: Hành vi trả về giá trị từ một phương thức thử nghiệm (khác với giá trị None mặc định) hiện không được dùng nữa.

Giao diện dòng lệnh

Mô-đun nhỏ nhất có thể được sử dụng từ dòng lệnh để chạy thử nghiệm từ các mô-đun, lớp hoặc thậm chí các phương thức thử nghiệm riêng lẻ

python -m unittest test_module1 test_module2
python -m unittest test_module.TestClass
python -m unittest test_module.TestClass.test_method

Bạn có thể chuyển vào một danh sách với bất kỳ sự kết hợp nào giữa tên mô-đun và tên lớp hoặc phương thức đủ điều kiện.

Các mô-đun thử nghiệm cũng có thể được chỉ định bằng đường dẫn tệp

python -m các bài kiểm tra không đáng tin cậy nhất/test_something.py

Điều này cho phép bạn sử dụng tính năng hoàn thành tên tệp shell để chỉ định mô-đun thử nghiệm. Tệp được chỉ định vẫn phải có thể nhập được dưới dạng mô-đun. Đường dẫn được chuyển đổi thành tên mô-đun bằng cách xóa '.py' và chuyển đổi dấu phân cách đường dẫn thành '.'. Nếu bạn muốn thực thi một tệp thử nghiệm không thể nhập được dưới dạng mô-đun, bạn nên thực thi tệp trực tiếp.

Bạn có thể chạy thử nghiệm với nhiều chi tiết hơn (mức độ chi tiết cao hơn) bằng cách chuyển vào cờ -v

python -m unittest -v test_module

Khi được thực thi mà không có đối số, Khám phá thử nghiệm sẽ được khởi động:

python -m không đáng tin cậy nhất

Để biết danh sách tất cả các tùy chọn dòng lệnh

python -m không đáng tin cậy nhất -h

Thay đổi trong phiên bản 3.2: Trong các phiên bản trước, chỉ có thể chạy các phương pháp thử nghiệm riêng lẻ chứ không thể chạy các mô-đun hoặc lớp.

Added in version 3.14: Đầu ra được tô màu theo mặc định và có thể là controlled using environment variables.

Tùy chọn dòng lệnh

unittest hỗ trợ các tùy chọn dòng lệnh sau:

-b, --buffer

Đầu ra tiêu chuẩn và luồng lỗi tiêu chuẩn được lưu vào bộ đệm trong quá trình chạy thử. Đầu ra trong quá trình vượt qua bài kiểm tra sẽ bị loại bỏ. Đầu ra được lặp lại bình thường khi kiểm tra không thành công hoặc có lỗi và được thêm vào các thông báo lỗi.

-c, --catch

Control-C trong quá trình chạy thử sẽ đợi quá trình kiểm tra hiện tại kết thúc rồi báo cáo tất cả kết quả cho đến thời điểm hiện tại. Control-C thứ hai sẽ đưa ra ngoại lệ KeyboardInterrupt bình thường.

Xem Signal Handling để biết các chức năng cung cấp chức năng này.

-f, --failfast

Dừng chạy thử khi có lỗi hoặc lỗi đầu tiên.

-k

Chỉ chạy các phương thức và lớp kiểm tra khớp với mẫu hoặc chuỗi con. Tùy chọn này có thể được sử dụng nhiều lần, trong trường hợp đó tất cả các trường hợp thử nghiệm khớp với bất kỳ mẫu nào đã cho đều được đưa vào.

Các mẫu chứa ký tự đại diện (*) được so khớp với tên thử nghiệm bằng fnmatch.fnmatchcase(); mặt khác, việc kết hợp chuỗi con phân biệt chữ hoa chữ thường đơn giản sẽ được sử dụng.

Các mẫu được so khớp với tên phương pháp thử nghiệm đủ điều kiện do trình tải thử nghiệm nhập vào.

Ví dụ: -k foo khớp với foo_tests.SomeTest.test_something, bar_tests.SomeTest.test_foo nhưng không khớp với bar_tests.FooTest.test_something.

--locals

Hiển thị các biến cục bộ trong truy nguyên.

--durations N

Hiển thị N trường hợp thử nghiệm chậm nhất (N=0 cho tất cả).

Added in version 3.2: Các tùy chọn dòng lệnh -b, -c và -f đã được thêm vào.

Added in version 3.5: Tùy chọn dòng lệnh --locals.

Added in version 3.7: Tùy chọn dòng lệnh -k.

Added in version 3.12: Tùy chọn dòng lệnh --durations.

Dòng lệnh cũng có thể được sử dụng để khám phá thử nghiệm, để chạy tất cả các thử nghiệm trong một dự án hoặc chỉ một tập hợp con.

Khám phá thử nghiệm

Added in version 3.2.

Unittest hỗ trợ khám phá thử nghiệm đơn giản. Để tương thích với khám phá thử nghiệm, tất cả các tệp thử nghiệm phải là modules hoặc packages có thể nhập được từ thư mục cấp cao nhất của dự án (điều này có nghĩa là tên tệp của chúng phải hợp lệ là identifiers).

Khám phá thử nghiệm được triển khai trong TestLoader.discover() nhưng cũng có thể được sử dụng từ dòng lệnh. Cách sử dụng dòng lệnh cơ bản là:

dự án cd_thư mục
python -m khám phá không đáng tin cậy nhất

Ghi chú

Là một phím tắt, python -m unittest tương đương với python -m unittest discover. Nếu bạn muốn truyền đối số để kiểm tra khám phá thì lệnh phụ discover phải được sử dụng một cách rõ ràng.

Lệnh phụ discover có các tùy chọn sau:

-v, --verbose

đầu ra dài dòng

-s, --start-directory directory

Thư mục để bắt đầu khám phá (mặc định .)

-p, --pattern pattern

Mẫu phù hợp với tệp thử nghiệm (mặc định test*.py)

-t, --top-level-directory directory

Thư mục cấp cao nhất của dự án (mặc định là thư mục bắt đầu)

Các tùy chọn -s, -p và -t có thể được chuyển vào dưới dạng đối số vị trí theo thứ tự đó. Hai dòng lệnh sau là tương đương:

python -m unittest khám phá -s project_directory -p "*_test.py"
python -m unittest khám phá project_directory "*_test.py"

Ngoài việc là một đường dẫn, bạn có thể chuyển tên gói, ví dụ myproject.subpackage.test, làm thư mục bắt đầu. Tên gói bạn cung cấp sau đó sẽ được nhập và vị trí của nó trên hệ thống tệp sẽ được sử dụng làm thư mục bắt đầu.

Cảnh báo

Khám phá kiểm tra tải các bài kiểm tra bằng cách nhập chúng. Sau khi khám phá kiểm tra đã tìm thấy tất cả các tệp kiểm tra từ thư mục bắt đầu mà bạn chỉ định, nó sẽ chuyển các đường dẫn thành tên gói để nhập. Ví dụ: foo/bar/baz.py sẽ được nhập dưới dạng foo.bar.baz.

Nếu bạn có một gói được cài đặt trên toàn cầu và thử khám phá thử nghiệm trên một bản sao khác của gói thì việc nhập could xảy ra không đúng chỗ. Nếu điều này xảy ra, khám phá thử nghiệm sẽ cảnh báo bạn và thoát.

Nếu bạn cung cấp thư mục bắt đầu dưới dạng tên gói thay vì đường dẫn đến thư mục thì khám phá sẽ giả định rằng bất kỳ vị trí nào mà nó nhập từ đó đều là vị trí bạn dự định, vì vậy bạn sẽ không nhận được cảnh báo.

Các mô-đun và gói thử nghiệm có thể tùy chỉnh tải và khám phá thử nghiệm thông qua load_tests protocol.

Thay đổi trong phiên bản 3.4: Khám phá thử nghiệm hỗ trợ namespace packages.

Thay đổi trong phiên bản 3.11: Khám phá thử nghiệm đã bỏ hỗ trợ namespace packages. Nó đã bị hỏng kể từ Python 3.7. Thư mục bắt đầu và các thư mục con chứa các bài kiểm tra phải là gói thông thường có tệp __init__.py.

Nếu thư mục bắt đầu là tên có dấu chấm của gói thì các gói tổ tiên có thể là các gói không gian tên.

Thay đổi trong phiên bản 3.14: Kiểm tra khám phá hỗ trợ namespace package làm thư mục bắt đầu lại. Để tránh quét các thư mục không liên quan đến Python, các bài kiểm tra không được tìm kiếm trong các thư mục con không chứa __init__.py.

Tổ chức mã kiểm tra

Các khối xây dựng cơ bản của thử nghiệm đơn vị là test cases --- các kịch bản đơn lẻ phải được thiết lập và kiểm tra tính chính xác. Trong unittest, các trường hợp thử nghiệm được biểu thị bằng các phiên bản unittest.TestCase. Để tạo các trường hợp thử nghiệm của riêng bạn, bạn phải viết các lớp con của TestCase hoặc sử dụng FunctionTestCase.

Mã thử nghiệm của phiên bản TestCase phải hoàn toàn khép kín, sao cho mã này có thể được chạy riêng lẻ hoặc kết hợp tùy ý với bất kỳ số lượng trường hợp thử nghiệm nào khác.

Lớp con TestCase đơn giản nhất sẽ chỉ triển khai một phương thức thử nghiệm (tức là một phương thức có tên bắt đầu bằng test) để thực hiện mã thử nghiệm cụ thể:

nhập khẩu đơn vị nhất

lớp DefaultWidgetSizeTestCase(unittest.TestCase):
    def test_default_widget_size (tự):
        widget = Widget('Tiện ích')
        self.assertEqual(widget.size(), (50, 50))

Lưu ý rằng để kiểm tra điều gì đó, chúng tôi sử dụng một trong các assert* methods được cung cấp bởi lớp cơ sở TestCase. Nếu thử nghiệm thất bại, một ngoại lệ sẽ được đưa ra cùng với thông báo giải thích và unittest sẽ xác định trường hợp thử nghiệm là failure. Bất kỳ trường hợp ngoại lệ nào khác sẽ được coi là errors.

Các thử nghiệm có thể có rất nhiều và việc thiết lập chúng có thể lặp đi lặp lại. May mắn thay, chúng ta có thể phân tích mã thiết lập bằng cách triển khai một phương thức có tên là setUp(), phương thức này sẽ tự động gọi cho mỗi thử nghiệm mà chúng ta chạy:

nhập khẩu đơn vị nhất

lớp WidgetTestCase(unittest.TestCase):
    def setUp(tự):
        self.widget = Widget('Tiện ích')

    def test_default_widget_size (tự):
        self.assertEqual(self.widget.size(), (50,50),
                         'kích thước mặc định không chính xác')

    def test_widget_resize(tự):
        self.widget.resize(100,150)
        self.assertEqual(self.widget.size(), (100,150),
                         'sai kích thước sau khi thay đổi kích thước')

Ghi chú

Thứ tự chạy các thử nghiệm khác nhau sẽ được xác định bằng cách sắp xếp các tên phương thức thử nghiệm theo thứ tự tích hợp cho chuỗi.

Nếu phương thức setUp() đưa ra một ngoại lệ trong khi thử nghiệm đang chạy, khung sẽ coi thử nghiệm đã gặp lỗi và phương thức thử nghiệm sẽ không được thực thi.

Tương tự, chúng tôi có thể cung cấp phương thức tearDown() để dọn dẹp sau khi phương thức thử nghiệm được chạy:

nhập khẩu đơn vị nhất

lớp WidgetTestCase(unittest.TestCase):
    def setUp(tự):
        self.widget = Widget('Tiện ích')

    def TearsDown(tự):
        self.widget.dispose()

Nếu setUp() thành công, tearDown() sẽ được chạy cho dù phương pháp thử nghiệm có thành công hay không.

Môi trường làm việc như vậy cho mã thử nghiệm được gọi là test fixture. Một phiên bản TestCase mới được tạo dưới dạng một bản cố định thử nghiệm duy nhất được sử dụng để thực thi từng phương pháp thử nghiệm riêng lẻ. Do đó, setUp(), tearDown() và TestCase.__init__() sẽ được gọi một lần cho mỗi lần kiểm tra.

Bạn nên sử dụng triển khai TestCase để nhóm các thử nghiệm lại với nhau theo các tính năng mà chúng thử nghiệm. unittest cung cấp cơ chế cho việc này: test suite, được đại diện bởi lớp TestSuite của unittest. Trong hầu hết các trường hợp, việc gọi unittest.main() sẽ thực hiện đúng và thu thập tất cả các trường hợp kiểm thử của mô-đun cho bạn rồi thực thi chúng.

Tuy nhiên, nếu bạn muốn tùy chỉnh việc xây dựng bộ thử nghiệm của mình, bạn có thể tự mình thực hiện:

bộ phần mềm chắc chắn():
    suite = unittest.TestSuite()
    suite.addTest(WidgetTestCase('test_default_widget_size'))
    suite.addTest(WidgetTestCase('test_widget_resize'))
    bộ trả về

nếu __name__ == '__main__':
    Á hậu = unittest.TextTestRunner()
    á hậu.run(bộ())

Bạn có thể đặt các định nghĩa về trường hợp kiểm thử và bộ kiểm thử trong cùng mô-đun với mã mà chúng sẽ kiểm tra (chẳng hạn như widget.py), nhưng có một số lợi ích khi đặt mã kiểm thử trong một mô-đun riêng biệt, chẳng hạn như test_widget.py:

• Mô-đun thử nghiệm có thể chạy độc lập từ dòng lệnh.

• Mã kiểm tra có thể dễ dàng được tách ra khỏi mã vận chuyển.

• Việc thay đổi mã kiểm tra để phù hợp với mã mà nó kiểm tra mà không có lý do chính đáng sẽ ít bị cám dỗ hơn.

• Mã kiểm tra nên được sửa đổi ít thường xuyên hơn mã mà nó kiểm tra.

• Mã đã kiểm tra có thể được tái cấu trúc dễ dàng hơn.

• Các thử nghiệm cho các mô-đun được viết bằng C dù sao cũng phải ở trong các mô-đun riêng biệt, vậy tại sao không nhất quán?

• Nếu chiến lược thử nghiệm thay đổi thì không cần thay đổi mã nguồn.

Sử dụng lại mã kiểm tra cũ

Một số người dùng sẽ thấy rằng họ có sẵn mã kiểm tra mà họ muốn chạy từ unittest mà không cần chuyển đổi mọi hàm kiểm tra cũ sang lớp con TestCase.

Vì lý do này, unittest cung cấp lớp FunctionTestCase. Lớp con này của TestCase có thể được sử dụng để bọc một hàm kiểm tra hiện có. Chức năng thiết lập và chia nhỏ cũng có thể được cung cấp.

Cho hàm kiểm tra sau:

kiểm tra chắc chắnS Something():
    cái gì đó = makeS Something()
    khẳng định cái gì đó.name không phải là Không
    # ...

người ta có thể tạo một phiên bản trường hợp thử nghiệm tương đương như sau, với các phương thức thiết lập và chia nhỏ tùy chọn:

testcase = unittest.FunctionTestCase(testSomething,
                                     setUp=makeS SomethingDB,
                                     TearsDown=xóaS SomethingDB)

Ghi chú

Mặc dù FunctionTestCase có thể được sử dụng để nhanh chóng chuyển đổi cơ sở thử nghiệm hiện có sang hệ thống dựa trên unittest- nhưng phương pháp này không được khuyến khích. Dành thời gian để thiết lập các lớp con TestCase thích hợp sẽ giúp việc tái cấu trúc thử nghiệm trong tương lai trở nên dễ dàng hơn rất nhiều.

Trong một số trường hợp, các bài kiểm tra hiện tại có thể đã được viết bằng mô-đun doctest. Nếu vậy, doctest cung cấp một lớp DocTestSuite có thể tự động xây dựng các phiên bản unittest.TestSuite từ các thử nghiệm dựa trên doctest- hiện có.

Bỏ qua các bài kiểm tra và thất bại dự kiến

Added in version 3.1.

Unittest hỗ trợ bỏ qua các phương pháp kiểm tra riêng lẻ và thậm chí cả lớp kiểm tra. Ngoài ra, nó hỗ trợ đánh dấu một bài kiểm tra là "thất bại dự kiến", một bài kiểm tra bị hỏng và sẽ thất bại nhưng không được tính là thất bại trên TestResult.

Bỏ qua kiểm tra chỉ đơn giản là sử dụng skip() decorator hoặc một trong các biến thể có điều kiện của nó, gọi TestCase.skipTest() trong setUp() hoặc phương pháp thử nghiệm hoặc trực tiếp nâng cao SkipTest.

Bỏ qua cơ bản trông như thế này:

lớp MyTestCase(unittest.TestCase):

    @unittest.skip("thể hiện việc bỏ qua")
    def test_nothing(self):
        self.fail("không nên xảy ra")

    @unittest.skipIf(mylib.__version__ < (1, 3),
                     "không được hỗ trợ trong phiên bản thư viện này")
    def test_format(tự):
        # Tests chỉ hoạt động với một phiên bản nhất định của thư viện.
        vượt qua

    @unittest.skipUnless(sys.platform.startswith("win"), "yêu cầu Windows")
    def test_windows_support(tự):
        mã kiểm tra cụ thể # windows
        vượt qua

    def test_maybe_skipped(tự):
        nếu không phải external_resource_available():
            self.skipTest("tài nguyên bên ngoài không có sẵn")
        Mã # test phụ thuộc vào tài nguyên bên ngoài
        vượt qua

Đây là kết quả của việc chạy ví dụ trên ở chế độ dài dòng:

test_format (__main__.MyTestCase.test_format) ... bị bỏ qua 'không được hỗ trợ trong phiên bản thư viện này'
test_nothing (__main__.MyTestCase.test_nothing) ... đã bỏ qua 'thể hiện việc bỏ qua'
test_maybe_skipped (__main__.MyTestCase.test_maybe_skipped) ... đã bỏ qua 'không có tài nguyên bên ngoài'
test_windows_support (__main__.MyTestCase.test_windows_support) ... đã bỏ qua 'yêu cầu Windows'

----------------------------------------------------------------------
Chạy 4 bài kiểm tra trong 0,005 giây

Được rồi (bỏ qua=4)

Các lớp có thể được bỏ qua giống như các phương thức:

@unittest.skip("hiển thị việc bỏ lớp")
lớp MySkippedTestCase(unittest.TestCase):
    def test_not_run(tự):
        vượt qua

TestCase.setUp() cũng có thể bỏ qua bài kiểm tra. Điều này rất hữu ích khi không có sẵn tài nguyên cần thiết lập.

Các lỗi dự kiến sẽ sử dụng công cụ trang trí expectedFailure().

lớp Dự kiếnFailureTestCase(unittest.TestCase):
    @unittest.expectedFailure
    def test_fail(tự):
        self.assertEqual(1, 0, "bị hỏng")

Thật dễ dàng để triển khai các trình trang trí bỏ qua của riêng bạn bằng cách tạo một trình trang trí gọi skip() trong bài kiểm tra khi nó muốn nó bị bỏ qua. Trình trang trí này bỏ qua bài kiểm tra trừ khi đối tượng được truyền có thuộc tính nhất định

def SkipUnlessHasattr(obj, attr):
    nếu hasattr(obj, attr):
        trả về hàm lambda: func
    return unittest.skip("{!r} không có {!r}".format(obj, attr))

Các trình trang trí và ngoại lệ sau đây triển khai việc bỏ qua kiểm thử và các lỗi dự kiến:

@unittest.skip(reason)

Vô điều kiện bỏ qua bài kiểm tra trang trí. reason sẽ mô tả lý do tại sao bài kiểm tra bị bỏ qua.

@unittest.skipIf(condition, reason)

Bỏ qua bài kiểm tra trang trí nếu condition là đúng.

@unittest.skipUnless(condition, reason)

Bỏ qua bài kiểm tra trang trí trừ khi condition là đúng.

@unittest.expectedFailure

Đánh dấu bài kiểm tra là một lỗi hoặc lỗi dự kiến. Nếu quá trình kiểm tra không thành công hoặc có lỗi trong chính chức năng kiểm tra (chứ không phải ở một trong các phương pháp test fixture) thì nó sẽ được coi là thành công. Nếu bài kiểm tra vượt qua, nó sẽ được coi là thất bại.

exception unittest.SkipTest(reason)

Ngoại lệ này được nêu ra để bỏ qua một bài kiểm tra.

Thông thường, bạn có thể sử dụng TestCase.skipTest() hoặc một trong các trình trang trí bỏ qua thay vì trực tiếp nâng cao phần này.

Các bài kiểm tra bị bỏ qua sẽ không có setUp() hoặc tearDown() chạy xung quanh chúng. Các lớp bị bỏ qua sẽ không chạy setUpClass() hoặc tearDownClass(). Các mô-đun bị bỏ qua sẽ không chạy được setUpModule() hoặc tearDownModule().

Phân biệt các lần lặp lại thử nghiệm bằng cách sử dụng các phép trừ

Added in version 3.4.

Khi có sự khác biệt rất nhỏ giữa các thử nghiệm của bạn, chẳng hạn như một số tham số, unittest cho phép bạn phân biệt chúng bên trong nội dung của phương thức thử nghiệm bằng trình quản lý bối cảnh subTest().

Ví dụ: bài kiểm tra sau:

lớp NumbersTest(unittest.TestCase):

    def test_even(tự):
        """
        Kiểm tra xem các số từ 0 đến 5 có phải là số chẵn không.
        """
        cho tôi trong phạm vi (0, 6):
            với self.subTest(i=i):
                self.assertEqual(i % 2, 0)

sẽ tạo ra đầu ra sau:

============================================================================
FAIL: test_even (__main__.NumbersTest.test_even) (i=1)
Kiểm tra xem các số từ 0 đến 5 có phải là số chẵn không.
----------------------------------------------------------------------
Traceback (cuộc gọi gần đây nhất):
  Tệp "subtests.py", dòng 11, trong test_even
    self.assertEqual(i % 2, 0)
    ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^
Khẳng địnhLỗi: 1 != 0

============================================================================
FAIL: test_even (__main__.NumbersTest.test_even) (i=3)
Kiểm tra xem các số từ 0 đến 5 có phải là số chẵn không.
----------------------------------------------------------------------
Traceback (cuộc gọi gần đây nhất):
  Tệp "subtests.py", dòng 11, trong test_even
    self.assertEqual(i % 2, 0)
    ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^
Khẳng địnhLỗi: 1 != 0

============================================================================
FAIL: test_even (__main__.NumbersTest.test_even) (i=5)
Kiểm tra xem các số từ 0 đến 5 có phải là số chẵn không.
----------------------------------------------------------------------
Traceback (cuộc gọi gần đây nhất):
  Tệp "subtests.py", dòng 11, trong test_even
    self.assertEqual(i % 2, 0)
    ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^
Khẳng địnhLỗi: 1 != 0

Nếu không sử dụng phép thử phụ, quá trình thực thi sẽ dừng sau lần thất bại đầu tiên và lỗi sẽ khó chẩn đoán hơn vì giá trị của i sẽ không được hiển thị:

============================================================================
FAIL: test_even (__main__.NumbersTest.test_even)
----------------------------------------------------------------------
Traceback (cuộc gọi gần đây nhất):
  Tệp "subtests.py", dòng 32, trong test_even
    self.assertEqual(i % 2, 0)
Khẳng địnhLỗi: 1 != 0

Các lớp và hàm

Phần này mô tả sâu về API của unittest.

Các trường hợp thử nghiệm

class unittest.TestCase(methodName='runTest')

Các phiên bản của lớp TestCase đại diện cho các đơn vị kiểm tra logic trong vũ trụ unittest. Lớp này nhằm mục đích sử dụng như một lớp cơ sở, với các bài kiểm tra cụ thể được thực hiện bởi các lớp con cụ thể. Lớp này triển khai giao diện mà người chạy thử nghiệm cần để cho phép nó thực hiện các thử nghiệm và các phương thức mà mã thử nghiệm có thể sử dụng để kiểm tra và báo cáo các loại lỗi khác nhau.

Mỗi phiên bản của TestCase sẽ chạy một phương thức cơ bản duy nhất: phương thức có tên methodName. Trong hầu hết các trường hợp sử dụng TestCase, bạn sẽ không thay đổi methodName cũng như không triển khai lại phương thức runTest() mặc định.

Thay đổi trong phiên bản 3.2: TestCase có thể được khởi tạo thành công mà không cần cung cấp methodName. Điều này giúp việc thử nghiệm TestCase từ trình thông dịch tương tác trở nên dễ dàng hơn.

Các phiên bản TestCase cung cấp ba nhóm phương pháp: một nhóm được sử dụng để chạy thử nghiệm, một nhóm khác được sử dụng để triển khai thử nghiệm để kiểm tra các điều kiện và báo cáo lỗi và một số phương pháp truy vấn cho phép thu thập thông tin về chính thử nghiệm đó.

Các phương thức trong nhóm đầu tiên (chạy thử nghiệm) là:

setUp()

Phương thức được gọi để chuẩn bị vật cố thử nghiệm. Điều này được gọi ngay trước khi gọi phương thức thử nghiệm; ngoài AssertionError hoặc SkipTest, mọi ngoại lệ được đưa ra bằng phương pháp này sẽ được coi là lỗi chứ không phải là lỗi kiểm tra. Việc triển khai mặc định không làm gì cả.

tearDown()

Phương thức được gọi ngay sau khi phương thức thử nghiệm được gọi và kết quả được ghi lại. Điều này được gọi ngay cả khi phương thức thử nghiệm đưa ra một ngoại lệ, do đó việc triển khai trong các lớp con có thể cần phải đặc biệt cẩn thận trong việc kiểm tra trạng thái bên trong. Bất kỳ ngoại lệ nào, ngoài AssertionError hoặc SkipTest, được đưa ra bằng phương pháp này sẽ được coi là lỗi bổ sung chứ không phải là lỗi kiểm tra (do đó làm tăng tổng số lỗi được báo cáo). Phương thức này sẽ chỉ được gọi nếu setUp() thành công, bất kể kết quả của phương thức thử nghiệm như thế nào. Việc triển khai mặc định không làm gì cả.

setUpClass()

Một phương thức lớp được gọi trước khi chạy thử nghiệm trong một lớp riêng lẻ. setUpClass được gọi với lớp là đối số duy nhất và phải được trang trí dưới dạng classmethod():

@classmethod
def setUpClass(cls):
    ...

Xem Class and Module Fixtures để biết thêm chi tiết.

Added in version 3.2.

tearDownClass()

Một phương thức lớp được gọi sau khi các bài kiểm tra trong một lớp riêng lẻ đã chạy. tearDownClass được gọi với lớp là đối số duy nhất và phải được trang trí dưới dạng classmethod():

@classmethod
def ripDownClass(cls):
    ...

Xem Class and Module Fixtures để biết thêm chi tiết.

Added in version 3.2.

run(result=None)

Chạy thử nghiệm, thu thập kết quả vào đối tượng TestResult được chuyển dưới dạng result. Nếu result bị bỏ qua hoặc None, một đối tượng kết quả tạm thời sẽ được tạo (bằng cách gọi phương thức defaultTestResult()) và được sử dụng. Đối tượng kết quả được trả về cho người gọi run().

Hiệu ứng tương tự có thể đạt được chỉ bằng cách gọi phiên bản TestCase.

Thay đổi trong phiên bản 3.3: Các phiên bản trước của run không trả về kết quả. Cũng không gọi một phiên bản.

skipTest(reason)

Việc gọi điều này trong phương pháp thử nghiệm hoặc setUp() sẽ bỏ qua thử nghiệm hiện tại. Xem Bỏ qua các bài kiểm tra và thất bại dự kiến để biết thêm thông tin.

Added in version 3.1.

subTest(msg=None, **params)

Trả về trình quản lý bối cảnh thực thi khối mã kèm theo dưới dạng kiểm tra phụ. msg và params là các giá trị tùy ý, tùy ý được hiển thị bất cứ khi nào thử nghiệm phụ không thành công, cho phép bạn xác định chúng một cách rõ ràng.

Một trường hợp kiểm thử có thể chứa bất kỳ số lượng khai báo kiểm tra phụ nào và chúng có thể được lồng vào nhau tùy ý.

Xem Phân biệt các lần lặp lại thử nghiệm bằng cách sử dụng các phép trừ để biết thêm thông tin.

Added in version 3.4.

debug()

Chạy thử nghiệm mà không thu thập kết quả. Điều này cho phép các ngoại lệ do thử nghiệm đưa ra được truyền tới phương thức gọi và có thể được sử dụng để hỗ trợ việc chạy thử nghiệm trong trình gỡ lỗi.

Lớp TestCase cung cấp một số phương thức xác nhận để kiểm tra và báo cáo lỗi. Bảng sau liệt kê các phương thức được sử dụng phổ biến nhất (xem bảng bên dưới để biết thêm các phương thức khẳng định):

phương pháp	Kiểm tra điều đó	Mới vào
assertEqual(a, b)	a == b
assertNotEqual(a, b)	a != b
assertTrue(x)	bool(x) is True
assertFalse(x)	bool(x) is False
assertIs(a, b)	a is b	3.1
assertIsNot(a, b)	a is not b	3.1
assertIsNone(x)	x is None	3.1
assertIsNotNone(x)	x is not None	3.1
assertIn(a, b)	a in b	3.1
assertNotIn(a, b)	a not in b	3.1
assertIsInstance(a, b)	isinstance(a, b)	3.2
assertNotIsInstance(a, b)	not isinstance(a, b)	3.2
assertIsSubclass(a, b)	issubclass(a, b)	3.14
assertNotIsSubclass(a, b)	not issubclass(a, b)	3.14

Tất cả các phương thức xác nhận đều chấp nhận đối số msg, nếu được chỉ định, sẽ được sử dụng làm thông báo lỗi khi xảy ra lỗi (xem thêm longMessage). Lưu ý rằng đối số từ khóa msg chỉ có thể được chuyển tới assertRaises(), assertRaisesRegex(), assertWarns(), assertWarnsRegex() khi chúng được sử dụng làm trình quản lý ngữ cảnh.

assertEqual(first, second, msg=None)

Kiểm tra xem first và second có bằng nhau không. Nếu các giá trị không so sánh bằng nhau, thử nghiệm sẽ thất bại.

Ngoài ra, nếu first và second là cùng một loại và là một trong các danh sách, tuple, dict, set, Frozenset hoặc str hoặc bất kỳ loại nào mà lớp con đăng ký với addTypeEqualityFunc() thì hàm đẳng thức dành riêng cho từng loại sẽ được gọi để tạo ra thông báo lỗi mặc định hữu ích hơn (xem thêm list of type-specific methods).

Thay đổi trong phiên bản 3.1: Đã thêm chức năng gọi tự động của hàm bình đẳng theo loại cụ thể.

Thay đổi trong phiên bản 3.2: assertMultiLineEqual() được thêm làm hàm bình đẳng loại mặc định để so sánh các chuỗi.

assertNotEqual(first, second, msg=None)

Kiểm tra xem first và second có bằng nhau không. Nếu các giá trị so sánh bằng nhau thì thử nghiệm sẽ thất bại.

assertTrue(expr, msg=None)

assertFalse(expr, msg=None)

Kiểm tra xem expr là đúng (hoặc sai).

Lưu ý rằng điều này tương đương với bool(expr) is True chứ không phải expr is True (sử dụng assertIs(expr, True) cho cái sau). Cũng nên tránh phương pháp này khi có sẵn các phương pháp cụ thể hơn (ví dụ: assertEqual(a, b) thay vì assertTrue(a == b)), vì chúng cung cấp thông báo lỗi tốt hơn trong trường hợp thất bại.

assertIs(first, second, msg=None)

assertIsNot(first, second, msg=None)

Kiểm tra xem first và second có phải (hoặc không) là cùng một đối tượng hay không.

Added in version 3.1.

assertIsNone(expr, msg=None)

assertIsNotNone(expr, msg=None)

Kiểm tra xem expr có phải (hoặc không) là None.

Added in version 3.1.

assertIn(member, container, msg=None)

assertNotIn(member, container, msg=None)

Kiểm tra xem member có (hoặc không) có trong container không.

Added in version 3.1.

assertIsInstance(obj, cls, msg=None)

assertNotIsInstance(obj, cls, msg=None)

Kiểm tra xem obj có phải (hoặc không phải) là một phiên bản của cls (có thể là một lớp hoặc một bộ các lớp, như được isinstance() hỗ trợ). Để kiểm tra loại chính xác, hãy sử dụng assertIs(type(obj), cls).

Added in version 3.2.

assertIsSubclass(cls, superclass, msg=None)

assertNotIsSubclass(cls, superclass, msg=None)

Kiểm tra xem cls có phải (hoặc không phải) là lớp con của superclass (có thể là một lớp hoặc một bộ lớp, như được issubclass() hỗ trợ). Để kiểm tra loại chính xác, hãy sử dụng assertIs(cls, superclass).

Added in version 3.14.

Cũng có thể kiểm tra việc tạo ra các ngoại lệ, cảnh báo và thông báo tường trình bằng các phương pháp sau:

phương pháp	Kiểm tra điều đó	Mới vào
assertRaises(exc, fun, *args, **kwds)	fun(*args, **kwds) tăng exc
assertRaisesRegex(exc, r, fun, *args, **kwds)	fun(*args, **kwds) tăng exc và thông báo khớp với biểu thức chính quy r	3.1
assertWarns(warn, fun, *args, **kwds)	fun(*args, **kwds) tăng warn	3.2
assertWarnsRegex(warn, r, fun, *args, **kwds)	fun(*args, **kwds) tăng warn và thông báo khớp với biểu thức chính quy r	3.2
assertLogs(logger, level)	Khối with đăng nhập vào logger với level tối thiểu	3,4
assertNoLogs(logger, level)	Khối with không đăng nhập được logger với level tối thiểu	3.10

assertRaises(exception, callable, *args, **kwds)

assertRaises(exception, *, msg=None)

Kiểm tra xem ngoại lệ có xuất hiện khi callable được gọi với bất kỳ đối số vị trí hoặc từ khóa nào cũng được chuyển đến assertRaises() hay không. Kiểm tra đạt nếu exception được nêu ra, là lỗi nếu một ngoại lệ khác được đưa ra hoặc không thành công nếu không có ngoại lệ nào được đưa ra. Để bắt bất kỳ nhóm ngoại lệ nào, một bộ chứa các lớp ngoại lệ có thể được chuyển dưới dạng exception.

Nếu chỉ cung cấp các đối số exception và có thể cả msg, hãy trả về trình quản lý bối cảnh để mã đang được kiểm tra có thể được viết nội dòng thay vì dưới dạng hàm:

với self.assertRaises(SomeException):
    làm_thứ gì đó()

Khi được sử dụng làm trình quản lý ngữ cảnh, assertRaises() chấp nhận đối số từ khóa bổ sung msg.

Trình quản lý bối cảnh sẽ lưu trữ đối tượng ngoại lệ bị bắt trong thuộc tính exception của nó. Điều này có thể hữu ích nếu có ý định thực hiện kiểm tra bổ sung đối với ngoại lệ được nêu ra:

với self.assertRaises(SomeException) là cm:
    làm_thứ gì đó()

the_Exception = cm.ngoại lệ
self.assertEqual(the_Exception.error_code, 3)

Thay đổi trong phiên bản 3.1: Đã thêm khả năng sử dụng assertRaises() làm trình quản lý bối cảnh.

Thay đổi trong phiên bản 3.2: Đã thêm thuộc tính exception.

Thay đổi trong phiên bản 3.3: Đã thêm đối số từ khóa msg khi được sử dụng làm trình quản lý bối cảnh.

assertRaisesRegex(exception, regex, callable, *args, **kwds)

assertRaisesRegex(exception, regex, *, msg=None)

Giống như assertRaises() nhưng cũng kiểm tra xem regex có khớp với biểu diễn chuỗi của ngoại lệ được nêu ra hay không. regex có thể là một đối tượng biểu thức chính quy hoặc một chuỗi chứa biểu thức chính quy phù hợp để re.search() sử dụng. Ví dụ:

self.assertRaisesRegex(ValueError, "chữ không hợp lệ cho.*XYZ'$",
                       int, 'XYZ')

hoặc:

với self.assertRaisesRegex(ValueError, 'literal'):
   int('XYZ')

Added in version 3.1: Đã thêm dưới tên assertRaisesRegexp.

Thay đổi trong phiên bản 3.2: Đổi tên thành assertRaisesRegex().

Thay đổi trong phiên bản 3.3: Đã thêm đối số từ khóa msg khi được sử dụng làm trình quản lý bối cảnh.

assertWarns(warning, callable, *args, **kwds)

assertWarns(warning, *, msg=None)

Kiểm tra xem cảnh báo có được kích hoạt khi callable được gọi với bất kỳ đối số vị trí hoặc từ khóa nào cũng được chuyển đến assertWarns() hay không. Kiểm tra đạt nếu warning được kích hoạt và thất bại nếu không. Bất kỳ ngoại lệ nào đều là lỗi. Để nắm bắt bất kỳ nhóm cảnh báo nào, một bộ dữ liệu chứa các lớp cảnh báo có thể được chuyển dưới dạng warnings.

Nếu chỉ cung cấp các đối số warning và có thể cả msg, hãy trả về trình quản lý bối cảnh để mã đang được kiểm tra có thể được viết nội dòng thay vì dưới dạng hàm:

với self.assertWarns(SomeWarning):
    làm_thứ gì đó()

Khi được sử dụng làm trình quản lý ngữ cảnh, assertWarns() chấp nhận đối số từ khóa bổ sung msg.

Trình quản lý bối cảnh sẽ lưu trữ đối tượng cảnh báo bị bắt trong thuộc tính warning của nó và dòng nguồn kích hoạt cảnh báo trong thuộc tính filename và lineno. Điều này có thể hữu ích nếu có ý định thực hiện kiểm tra bổ sung đối với cảnh báo được phát hiện:

với self.assertWarns(SomeWarning) là cm:
    làm_thứ gì đó()

self.assertIn('myfile.py', cm.filename)
self.assertEqual(320, cm.lineno)

Phương pháp này hoạt động bất kể bộ lọc cảnh báo được áp dụng khi nó được gọi.

Added in version 3.2.

Thay đổi trong phiên bản 3.3: Đã thêm đối số từ khóa msg khi được sử dụng làm trình quản lý bối cảnh.

assertWarnsRegex(warning, regex, callable, *args, **kwds)

assertWarnsRegex(warning, regex, *, msg=None)

Giống như assertWarns() nhưng cũng kiểm tra xem regex có khớp với thông báo cảnh báo được kích hoạt hay không. regex có thể là một đối tượng biểu thức chính quy hoặc một chuỗi chứa biểu thức chính quy phù hợp để re.search() sử dụng. Ví dụ:

self.assertWarnsRegex(Không dùng nữaCảnh báo,
                      r'legacy_function\(\) không được dùng nữa',
                      di sản_function, 'XYZ')

hoặc:

với self.assertWarnsRegex(RuntimeWarning, 'làm lạnh không an toàn'):
    đông lạnh('/etc/passwd')

Added in version 3.2.

Thay đổi trong phiên bản 3.3: Đã thêm đối số từ khóa msg khi được sử dụng làm trình quản lý bối cảnh.

assertLogs(logger=None, level=None)

Trình quản lý bối cảnh để kiểm tra xem có ít nhất một tin nhắn được ghi vào logger hoặc một trong các phần tử con của nó hay không, với ít nhất level đã cho.

Nếu được cung cấp, logger phải là đối tượng logging.Logger hoặc str đặt tên của trình ghi nhật ký. Mặc định là trình ghi nhật ký gốc, nó sẽ ghi lại tất cả các tin nhắn không bị chặn bởi trình ghi nhật ký con cháu không lan truyền.

Nếu được cung cấp, level phải ở mức ghi nhật ký số hoặc chuỗi tương đương của nó (ví dụ: "ERROR" hoặc logging.ERROR). Mặc định là logging.INFO.

Quá trình kiểm tra đạt nếu ít nhất một thông báo được phát ra bên trong khối with phù hợp với các điều kiện logger và level, nếu không thì nó sẽ thất bại.

Đối tượng được trình quản lý bối cảnh trả về là một trình trợ giúp ghi âm giúp theo dõi các thông điệp tường trình phù hợp. Nó có hai thuộc tính:

records

Danh sách các đối tượng logging.LogRecord của thông điệp tường trình phù hợp.

output

Danh sách các đối tượng str với đầu ra được định dạng của các thông báo phù hợp.

Ví dụ:

với self.assertLogs('foo', level='INFO') là cm:
    logging.getLogger('foo').info('tin nhắn đầu tiên')
    logging.getLogger('foo.bar').error('tin nhắn thứ hai')
self.assertEqual(cm.output, ['INFO:foo:tin nhắn đầu tiên',
                             'ERROR:foo.bar:tin nhắn thứ hai'])

Added in version 3.4.

assertNoLogs(logger=None, level=None)

Trình quản lý bối cảnh để kiểm tra xem không có tin nhắn nào được ghi vào logger hoặc một trong các phần tử con của nó, với ít nhất level đã cho.

Nếu được cung cấp, logger phải là đối tượng logging.Logger hoặc str đặt tên của trình ghi nhật ký. Mặc định là trình ghi nhật ký gốc, nó sẽ ghi lại tất cả các tin nhắn.

Nếu được cung cấp, level phải ở mức ghi nhật ký số hoặc chuỗi tương đương của nó (ví dụ: "ERROR" hoặc logging.ERROR). Mặc định là logging.INFO.

Không giống như assertLogs(), trình quản lý bối cảnh sẽ không trả về gì cả.

Added in version 3.10.

Ngoài ra còn có các phương pháp khác được sử dụng để thực hiện kiểm tra cụ thể hơn, chẳng hạn như:

phương pháp	Kiểm tra điều đó	Mới vào
assertAlmostEqual(a, b)	round(a-b, 7) == 0
assertNotAlmostEqual(a, b)	round(a-b, 7) != 0
assertGreater(a, b)	a > b	3.1
assertGreaterEqual(a, b)	a >= b	3.1
assertLess(a, b)	a < b	3.1
assertLessEqual(a, b)	a <= b	3.1
assertRegex(s, r)	r.search(s)	3.1
assertNotRegex(s, r)	not r.search(s)	3.2
assertCountEqual(a, b)	a chứa các phần tử giống như b, bất kể thứ tự của chúng.	3.2
assertStartsWith(a, b)	a.startswith(b)	3.14
assertNotStartsWith(a, b)	not a.startswith(b)	3.14
assertEndsWith(a, b)	a.endswith(b)	3.14
assertNotEndsWith(a, b)	not a.endswith(b)	3.14
assertHasAttr(a, b)	hastattr(a, b)	3.14
assertNotHasAttr(a, b)	not hastattr(a, b)	3.14

assertAlmostEqual(first, second, places=7, msg=None, delta=None)

assertNotAlmostEqual(first, second, places=7, msg=None, delta=None)

Kiểm tra xem first và second có xấp xỉ (hoặc không xấp xỉ) bằng nhau hay không bằng cách tính hiệu, làm tròn đến số thập phân places đã cho (mặc định là 7) và so sánh với 0. Lưu ý rằng các phương thức này làm tròn các giá trị thành số decimal places đã cho (tức là giống như hàm round()) chứ không phải significant digits.

Nếu delta được cung cấp thay vì places thì sự khác biệt giữa first và second phải nhỏ hơn hoặc bằng (hoặc lớn hơn) delta.

Cung cấp cả delta và places sẽ tăng TypeError.

Thay đổi trong phiên bản 3.2: assertAlmostEqual() tự động xem xét các đối tượng gần như bằng nhau để so sánh bằng nhau. assertNotAlmostEqual() tự động bị lỗi nếu các đối tượng so sánh bằng nhau. Đã thêm đối số từ khóa delta.

assertGreater(first, second, msg=None)

assertGreaterEqual(first, second, msg=None)

assertLess(first, second, msg=None)

assertLessEqual(first, second, msg=None)

Kiểm tra xem first lần lượt là >, >=, < hoặc <= hơn second tùy thuộc vào tên phương thức. Nếu không, bài kiểm tra sẽ thất bại:

>>> self.assertGreaterEqual(3, 4)
AssertionError: "3" bất ngờ không lớn hơn hoặc bằng "4"

Added in version 3.1.

assertRegex(text, regex, msg=None)

assertNotRegex(text, regex, msg=None)

Kiểm tra xem tìm kiếm regex có khớp (hoặc không khớp) với text không. Trong trường hợp thất bại, thông báo lỗi sẽ bao gồm mẫu và text (hoặc mẫu và phần text trùng khớp bất ngờ). regex có thể là một đối tượng biểu thức chính quy hoặc một chuỗi chứa biểu thức chính quy phù hợp để re.search() sử dụng.

Added in version 3.1: Đã thêm dưới tên assertRegexpMatches.

Thay đổi trong phiên bản 3.2: Phương thức assertRegexpMatches() đã được đổi tên thành assertRegex().

Added in version 3.2: assertNotRegex().

assertCountEqual(first, second, msg=None)

Kiểm tra xem chuỗi first có chứa các phần tử giống như second hay không, bất kể thứ tự của chúng. Khi không, một thông báo lỗi liệt kê sự khác biệt giữa các chuỗi sẽ được tạo.

Các phần tử trùng lặp bị not bỏ qua khi so sánh first và second. Nó xác minh xem mỗi phần tử có cùng số lượng trong cả hai chuỗi hay không. Tương đương với: assertEqual(Counter(list(first)), Counter(list(second))) nhưng cũng hoạt động với chuỗi các đối tượng không thể băm được.

Added in version 3.2.

assertStartsWith(s, prefix, msg=None)

assertNotStartsWith(s, prefix, msg=None)

Kiểm tra xem chuỗi Unicode hoặc chuỗi byte s có bắt đầu (hoặc không bắt đầu) bằng prefix hay không. prefix cũng có thể là một bộ chuỗi để thử.

Added in version 3.14.

assertEndsWith(s, suffix, msg=None)

assertNotEndsWith(s, suffix, msg=None)

Kiểm tra xem chuỗi Unicode hoặc chuỗi byte s có kết thúc (hoặc không kết thúc) bằng suffix hay không. suffix cũng có thể là một bộ chuỗi để thử.

Added in version 3.14.

assertHasAttr(obj, name, msg=None)

assertNotHasAttr(obj, name, msg=None)

Kiểm tra xem đối tượng obj có (hoặc không có) thuộc tính name.

Added in version 3.14.

Phương thức assertEqual() gửi kiểm tra tính bằng nhau cho các đối tượng cùng loại tới các phương thức dành riêng cho từng loại khác nhau. Các phương thức này đã được triển khai cho hầu hết các loại tích hợp sẵn, nhưng cũng có thể đăng ký các phương thức mới bằng addTypeEqualityFunc():

addTypeEqualityFunc(typeobj, function)

Đăng ký một phương thức dành riêng cho từng loại được gọi bởi assertEqual() để kiểm tra xem hai đối tượng của typeobj giống hệt nhau (không phải lớp con) có so sánh bằng nhau hay không. function phải lấy hai đối số vị trí và một đối số từ khóa thứ ba msg=None giống như assertEqual(). Nó phải tăng self.failureException(msg) khi phát hiện sự bất bình đẳng giữa hai tham số đầu tiên -- có thể cung cấp thông tin hữu ích và giải thích chi tiết về sự bất bình đẳng trong thông báo lỗi.

Added in version 3.1.

Danh sách các phương thức dành riêng cho từng loại được assertEqual() tự động sử dụng được tóm tắt trong bảng sau. Lưu ý rằng thường không cần thiết phải gọi trực tiếp các phương thức này.

phương pháp	Dùng để so sánh	Mới vào
assertMultiLineEqual(a, b)	dây	3.1
assertSequenceEqual(a, b)	trình tự	3.1
assertListEqual(a, b)	danh sách	3.1
assertTupleEqual(a, b)	bộ dữ liệu	3.1
assertSetEqual(a, b)	bộ hoặc bộ đông lạnh	3.1
assertDictEqual(a, b)	mệnh lệnh	3.1

assertMultiLineEqual(first, second, msg=None)

Kiểm tra xem chuỗi nhiều dòng first có bằng chuỗi second không. Khi độ khác biệt của hai chuỗi không bằng nhau, làm nổi bật sự khác biệt sẽ được đưa vào thông báo lỗi. Phương pháp này được sử dụng theo mặc định khi so sánh chuỗi với assertEqual().

Added in version 3.1.

assertSequenceEqual(first, second, msg=None, seq_type=None)

Kiểm tra hai chuỗi bằng nhau. Nếu seq_type được cung cấp, cả first và second đều phải là phiên bản của seq_type, nếu không sẽ xảy ra lỗi. Nếu các trình tự khác nhau, một thông báo lỗi sẽ được tạo ra cho thấy sự khác biệt giữa hai trình tự.

Phương thức này không được assertEqual() gọi trực tiếp nhưng nó được sử dụng để triển khai assertListEqual() và assertTupleEqual().

Added in version 3.1.

assertListEqual(first, second, msg=None)

assertTupleEqual(first, second, msg=None)

Kiểm tra xem hai danh sách hoặc bộ dữ liệu có bằng nhau không. Nếu không, một thông báo lỗi sẽ được tạo ra để chỉ hiển thị sự khác biệt giữa hai thông báo này. Lỗi cũng xuất hiện nếu một trong hai tham số sai loại. Các phương thức này được sử dụng theo mặc định khi so sánh danh sách hoặc bộ dữ liệu với assertEqual().

Added in version 3.1.

assertSetEqual(first, second, msg=None)

Kiểm tra hai bộ bằng nhau. Nếu không, một thông báo lỗi sẽ được tạo để liệt kê những khác biệt giữa các bộ. Phương pháp này được sử dụng theo mặc định khi so sánh các tập hợp hoặc tập hợp cố định với assertEqual().

Không thành công nếu một trong hai first hoặc second không có phương thức difference().

Added in version 3.1.

assertDictEqual(first, second, msg=None)

Kiểm tra xem hai từ điển có bằng nhau không. Nếu không, một thông báo lỗi sẽ được tạo để hiển thị sự khác biệt trong từ điển. Phương pháp này sẽ được sử dụng theo mặc định để so sánh các từ điển trong lệnh gọi tới assertEqual().

Added in version 3.1.

Cuối cùng, TestCase cung cấp các phương thức và thuộc tính sau:

fail(msg=None)

Báo hiệu lỗi kiểm tra vô điều kiện, với msg hoặc None cho thông báo lỗi.

failureException

Thuộc tính lớp này đưa ra ngoại lệ được đưa ra bởi phương thức thử nghiệm. Nếu một khung kiểm thử cần sử dụng một ngoại lệ chuyên biệt, có thể mang thông tin bổ sung, thì nó phải phân lớp ngoại lệ này để "chơi công bằng" với khung. Giá trị ban đầu của thuộc tính này là AssertionError.

longMessage

Thuộc tính lớp này xác định điều gì sẽ xảy ra khi một thông báo lỗi tùy chỉnh được chuyển dưới dạng đối số msg cho lệnh gọi khẳng địnhXYY không thành công. True là giá trị mặc định. Trong trường hợp này, thông báo tùy chỉnh sẽ được thêm vào cuối thông báo lỗi tiêu chuẩn. Khi được đặt thành False, thông báo tùy chỉnh sẽ thay thế thông báo tiêu chuẩn.

Cài đặt lớp có thể được ghi đè trong các phương thức thử nghiệm riêng lẻ bằng cách gán một thuộc tính phiên bản, self.longMessage, cho True hoặc False trước khi gọi các phương thức xác nhận.

Cài đặt lớp được đặt lại trước mỗi cuộc gọi kiểm tra.

Added in version 3.1.

maxDiff

Thuộc tính này kiểm soát độ dài tối đa của đầu ra khác biệt bằng các phương thức xác nhận báo cáo khác biệt về lỗi. Nó mặc định là 80*8 ký tự. Các phương thức xác nhận bị ảnh hưởng bởi thuộc tính này là assertSequenceEqual() (bao gồm tất cả các phương thức so sánh trình tự được ủy quyền cho nó), assertDictEqual() và assertMultiLineEqual().

Đặt maxDiff thành None có nghĩa là không có độ dài khác biệt tối đa.

Added in version 3.2.

Khung kiểm tra có thể sử dụng các phương pháp sau để thu thập thông tin về bài kiểm tra:

countTestCases()

Trả về số lượng thử nghiệm được đại diện bởi đối tượng thử nghiệm này. Đối với các phiên bản TestCase, giá trị này sẽ luôn là 1.

defaultTestResult()

Trả về một phiên bản của lớp kết quả kiểm tra sẽ được sử dụng cho lớp trường hợp kiểm thử này (nếu không có phiên bản kết quả nào khác được cung cấp cho phương thức run()).

Đối với các phiên bản TestCase, đây sẽ luôn là phiên bản của TestResult; các lớp con của TestCase sẽ ghi đè lên điều này nếu cần thiết.

id()

Trả về một chuỗi xác định trường hợp thử nghiệm cụ thể. Đây thường là tên đầy đủ của phương thức thử nghiệm, bao gồm tên mô-đun và tên lớp.

shortDescription()

Trả về mô tả của bài kiểm tra hoặc None nếu không có mô tả nào được cung cấp. Việc triển khai mặc định của phương thức này trả về dòng đầu tiên của chuỗi tài liệu của phương thức thử nghiệm, nếu có hoặc None.

Thay đổi trong phiên bản 3.1: Trong 3.1, điều này đã được thay đổi để thêm tên kiểm tra vào mô tả ngắn ngay cả khi có chuỗi tài liệu. Điều này gây ra sự cố tương thích với các tiện ích mở rộng nhỏ nhất và việc thêm tên thử nghiệm đã được chuyển sang TextTestResult trong Python 3.2.

addCleanup(function, /, *args, **kwargs)

Thêm một hàm được gọi sau tearDown() để dọn sạch các tài nguyên được sử dụng trong quá trình thử nghiệm. Các hàm sẽ được gọi theo thứ tự ngược lại với thứ tự chúng được thêm vào (LIFO). Chúng được gọi với bất kỳ đối số và đối số từ khóa nào được chuyển vào addCleanup() khi chúng được thêm vào.

Nếu setUp() không thành công, nghĩa là tearDown() không được gọi thì mọi chức năng dọn dẹp được thêm vào sẽ vẫn được gọi.

Added in version 3.1.

enterContext(cm)

Nhập context manager được cung cấp. Nếu thành công, hãy thêm phương thức __exit__() của nó làm hàm dọn dẹp bằng addCleanup() và trả về kết quả của phương thức __enter__().

Added in version 3.11.

doCleanups()

Phương thức này được gọi vô điều kiện sau tearDown() hoặc sau setUp() nếu setUp() đưa ra một ngoại lệ.

Nó chịu trách nhiệm gọi tất cả các chức năng dọn dẹp được thêm bởi addCleanup(). Nếu bạn cần các chức năng dọn dẹp được gọi là prior đến tearDown() thì bạn có thể tự gọi doCleanups().

doCleanups() lần lượt bật ra các phương thức khỏi ngăn xếp các hàm dọn dẹp, do đó, nó có thể được gọi bất cứ lúc nào.

Added in version 3.1.

classmethod addClassCleanup(function, /, *args, **kwargs)

Thêm một hàm được gọi sau tearDownClass() để dọn sạch các tài nguyên được sử dụng trong lớp kiểm tra. Các hàm sẽ được gọi theo thứ tự ngược lại với thứ tự chúng được thêm vào (LIFO). Chúng được gọi với bất kỳ đối số và đối số từ khóa nào được chuyển vào addClassCleanup() khi chúng được thêm vào.

Nếu setUpClass() không thành công, nghĩa là tearDownClass() không được gọi thì mọi chức năng dọn dẹp được thêm vào sẽ vẫn được gọi.

Added in version 3.8.

classmethod enterClassContext(cm)

Nhập context manager được cung cấp. Nếu thành công, hãy thêm phương thức __exit__() của nó làm hàm dọn dẹp bằng addClassCleanup() và trả về kết quả của phương thức __enter__().

Added in version 3.11.

classmethod doClassCleanups()

Phương thức này được gọi vô điều kiện sau tearDownClass() hoặc sau setUpClass() nếu setUpClass() đưa ra một ngoại lệ.

Nó chịu trách nhiệm gọi tất cả các chức năng dọn dẹp được thêm bởi addClassCleanup(). Nếu bạn cần các chức năng dọn dẹp được gọi là prior đến tearDownClass() thì bạn có thể tự gọi doClassCleanups().

doClassCleanups() lần lượt bật ra các phương thức khỏi ngăn xếp các hàm dọn dẹp, do đó, nó có thể được gọi bất cứ lúc nào.

Added in version 3.8.

class unittest.IsolatedAsyncioTestCase(methodName='runTest')

Lớp này cung cấp một API tương tự như TestCase và cũng chấp nhận coroutine làm hàm kiểm tra.

Added in version 3.8.

loop_factory

loop_factory được chuyển tới asyncio.Runner. Ghi đè trong các lớp con bằng asyncio.EventLoop để tránh sử dụng hệ thống chính sách asyncio.

Added in version 3.13.

async asyncSetUp()

Phương thức được gọi để chuẩn bị vật cố thử nghiệm. Điều này được gọi sau TestCase.setUp(). Điều này được gọi ngay trước khi gọi phương thức thử nghiệm; ngoài AssertionError hoặc SkipTest, bất kỳ ngoại lệ nào được đưa ra bằng phương pháp này sẽ được coi là lỗi chứ không phải là lỗi kiểm tra. Việc triển khai mặc định không làm gì cả.

async asyncTearDown()

Phương thức được gọi ngay sau khi phương thức thử nghiệm được gọi và kết quả được ghi lại. Điều này được gọi trước tearDown(). Điều này được gọi ngay cả khi phương thức thử nghiệm đưa ra một ngoại lệ, do đó việc triển khai trong các lớp con có thể cần phải đặc biệt cẩn thận trong việc kiểm tra trạng thái bên trong. Bất kỳ ngoại lệ nào, ngoại trừ AssertionError hoặc SkipTest, được đưa ra bằng phương pháp này sẽ được coi là lỗi bổ sung chứ không phải là lỗi kiểm tra (do đó làm tăng tổng số lỗi được báo cáo). Phương thức này sẽ chỉ được gọi nếu asyncSetUp() thành công, bất kể kết quả của phương thức thử nghiệm như thế nào. Việc triển khai mặc định không làm gì cả.

addAsyncCleanup(function, /, *args, **kwargs)

Phương thức này chấp nhận một coroutine có thể được sử dụng làm hàm dọn dẹp.

async enterAsyncContext(cm)

Nhập asynchronous context manager được cung cấp. Nếu thành công, hãy thêm phương thức __aexit__() của nó làm hàm dọn dẹp bằng addAsyncCleanup() và trả về kết quả của phương thức __aenter__().

Added in version 3.11.

run(result=None)

Thiết lập vòng lặp sự kiện mới để chạy thử nghiệm, thu thập kết quả vào đối tượng TestResult được chuyển dưới dạng result. Nếu result bị bỏ qua hoặc None, một đối tượng kết quả tạm thời sẽ được tạo (bằng cách gọi phương thức defaultTestResult()) và được sử dụng. Đối tượng kết quả được trả về cho người gọi run(). Khi kết thúc quá trình kiểm tra, tất cả các tác vụ trong vòng lặp sự kiện sẽ bị hủy.

Ví dụ minh họa thứ tự:

từ nhập khẩu unittest IsolatAsyncioTestCase

sự kiện = []


Kiểm tra lớp (IsolatedAsyncioTestCase):


    def setUp(tự):
        events.append("setUp")

    async def asyncSetUp(self):
        self._async_connection = đang chờ AsyncConnection()
        events.append("asyncSetUp")

    async def test_response(self):
        events.append("test_response")
        phản hồi = đang chờ self._async_connection.get("https://example.com")
        self.assertEqual(response.status_code, 200)
        self.addAsyncCleanup(self.on_cleanup)

    def TearsDown(tự):
        events.append("tearDown")

    async def asyncTearDown(self):
        đang chờ self._async_connection.close()
        events.append("asyncTearDown")

    async def on_cleanup(self):
        events.append("dọn dẹp")

nếu __name__ == "__main__":
    unittest.main()

Sau khi chạy thử nghiệm, events sẽ chứa ["setUp", "asyncSetUp", "test_response", "asyncTearDown", "tearDown", "cleanup"].

class unittest.FunctionTestCase(testFunc, setUp=None, tearDown=None, description=None)

Lớp này triển khai phần giao diện TestCase cho phép người chạy thử nghiệm thực hiện thử nghiệm nhưng không cung cấp các phương thức mà mã thử nghiệm có thể sử dụng để kiểm tra và báo cáo lỗi. Điều này được sử dụng để tạo các trường hợp thử nghiệm bằng cách sử dụng mã thử nghiệm cũ, cho phép nó được tích hợp vào khung thử nghiệm dựa trên unittest.

Kiểm tra nhóm

class unittest.TestSuite(tests=())

Lớp này đại diện cho một tập hợp các trường hợp thử nghiệm và bộ thử nghiệm riêng lẻ. Lớp này trình bày giao diện mà người chạy thử nghiệm cần để cho phép nó chạy như mọi trường hợp thử nghiệm khác. Chạy phiên bản TestSuite cũng giống như lặp lại bộ phần mềm, chạy từng thử nghiệm riêng lẻ.

Nếu tests được cung cấp, nó phải là một trường hợp thử nghiệm riêng lẻ có thể lặp lại hoặc các bộ thử nghiệm khác sẽ được sử dụng để xây dựng bộ phần mềm ban đầu. Các phương pháp bổ sung được cung cấp để thêm các trường hợp và bộ thử nghiệm vào bộ sưu tập sau này.

Đối tượng TestSuite hoạt động giống như đối tượng TestCase, ngoại trừ việc chúng không thực sự triển khai thử nghiệm. Thay vào đó, chúng được sử dụng để tổng hợp các thử nghiệm thành các nhóm thử nghiệm cần được chạy cùng nhau. Một số phương pháp bổ sung có sẵn để thêm thử nghiệm vào phiên bản TestSuite:

addTest(test)

Thêm TestCase hoặc TestSuite vào bộ phần mềm.

addTests(tests)

Thêm tất cả các thử nghiệm từ các phiên bản TestCase và TestSuite lặp lại vào bộ thử nghiệm này.

Điều này tương đương với việc lặp lại tests, gọi addTest() cho từng phần tử.

TestSuite chia sẻ các phương pháp sau với TestCase:

run(result)

Chạy các thử nghiệm liên quan đến bộ phần mềm này, thu thập kết quả vào đối tượng kết quả thử nghiệm được chuyển dưới dạng result. Lưu ý rằng không giống như TestCase.run(), TestSuite.run() yêu cầu đối tượng kết quả phải được truyền vào.

debug()

Chạy các thử nghiệm liên quan đến bộ phần mềm này mà không thu thập kết quả. Điều này cho phép các ngoại lệ do thử nghiệm đưa ra được truyền tới phương thức gọi và có thể được sử dụng để hỗ trợ việc chạy thử nghiệm trong trình gỡ lỗi.

countTestCases()

Trả về số lượng thử nghiệm được đại diện bởi đối tượng thử nghiệm này, bao gồm tất cả các thử nghiệm riêng lẻ và các bộ phụ.

__iter__()

Các thử nghiệm được nhóm theo TestSuite luôn được truy cập bằng cách lặp lại. Các lớp con có thể cung cấp các bài kiểm tra một cách lười biếng bằng cách ghi đè __iter__(). Lưu ý rằng phương thức này có thể được gọi nhiều lần trên một bộ đơn lẻ (ví dụ: khi đếm các bài kiểm tra hoặc so sánh sự bằng nhau) vì vậy các bài kiểm tra được trả về bằng các lần lặp lại trước TestSuite.run() phải giống nhau cho mỗi lần lặp cuộc gọi. Sau TestSuite.run(), người gọi không nên dựa vào các kiểm tra được phương thức này trả về trừ khi người gọi sử dụng lớp con ghi đè TestSuite._removeTestAtIndex() để duy trì các tham chiếu kiểm tra.

Thay đổi trong phiên bản 3.2: Trong các phiên bản trước, TestSuite truy cập các bài kiểm tra một cách trực tiếp thay vì thông qua việc lặp lại, do đó, việc ghi đè __iter__() là không đủ để cung cấp các bài kiểm tra.

Thay đổi trong phiên bản 3.4: Trong các phiên bản trước, TestSuite giữ các tham chiếu đến từng TestCase sau TestSuite.run(). Các lớp con có thể khôi phục hành vi đó bằng cách ghi đè TestSuite._removeTestAtIndex().

Trong cách sử dụng thông thường của đối tượng TestSuite, phương thức run() được gọi bởi TestRunner chứ không phải bởi khai thác thử nghiệm của người dùng cuối.

Đang tải và chạy thử nghiệm

class unittest.TestLoader

Lớp TestLoader được sử dụng để tạo bộ thử nghiệm từ các lớp và mô-đun. Thông thường, không cần tạo một thể hiện của lớp này; mô-đun unittest cung cấp một phiên bản có thể được chia sẻ dưới dạng unittest.defaultTestLoader. Tuy nhiên, việc sử dụng một lớp con hoặc phiên bản cho phép tùy chỉnh một số thuộc tính có thể định cấu hình.

Các đối tượng TestLoader có các thuộc tính sau:

errors

Danh sách các lỗi không nghiêm trọng gặp phải khi tải bài kiểm tra. Không được thiết lập lại bởi bộ nạp tại bất kỳ thời điểm nào. Các lỗi nghiêm trọng được báo hiệu bằng phương pháp liên quan đưa ra một ngoại lệ cho người gọi. Các lỗi không nghiêm trọng cũng được biểu thị bằng một thử nghiệm tổng hợp sẽ làm xuất hiện lỗi ban đầu khi chạy.

Added in version 3.5.

Các đối tượng TestLoader có các phương thức sau:

loadTestsFromTestCase(testCaseClass)

Trả về một bộ gồm tất cả các trường hợp thử nghiệm có trong TestCase-có nguồn gốc từ testCaseClass.

Một phiên bản trường hợp thử nghiệm được tạo cho mỗi phương thức được đặt tên bởi getTestCaseNames(). Theo mặc định đây là tên phương thức bắt đầu bằng test. Nếu getTestCaseNames() không trả về phương thức nào nhưng phương thức runTest() được triển khai thì thay vào đó, một trường hợp thử nghiệm sẽ được tạo cho phương thức đó.

loadTestsFromModule(module, *, pattern=None)

Trả về một bộ tất cả các trường hợp thử nghiệm có trong mô-đun đã cho. Phương thức này tìm kiếm module các lớp bắt nguồn từ TestCase và tạo một phiên bản của lớp cho mỗi phương thức thử nghiệm được xác định cho lớp đó.

Ghi chú

Mặc dù việc sử dụng hệ thống phân cấp của các lớp TestCase- có nguồn gốc có thể thuận tiện trong việc chia sẻ các cố định và hàm trợ giúp, nhưng việc xác định các phương thức kiểm tra trên các lớp cơ sở không nhằm mục đích khởi tạo trực tiếp sẽ không phù hợp với phương thức này. Tuy nhiên, làm như vậy có thể hữu ích khi các đồ đạc khác nhau và được xác định trong các lớp con.

Nếu một mô-đun cung cấp chức năng load_tests, nó sẽ được gọi để tải các bài kiểm tra. Điều này cho phép các mô-đun tùy chỉnh tải thử nghiệm. Đây là load_tests protocol. Đối số pattern được chuyển làm đối số thứ ba cho load_tests.

Thay đổi trong phiên bản 3.2: Đã thêm hỗ trợ cho load_tests.

Thay đổi trong phiên bản 3.5: Hỗ trợ cho đối số chỉ từ khóa pattern đã được thêm vào.

Thay đổi trong phiên bản 3.12: Tham số use_load_tests không có giấy tờ và không chính thức đã bị xóa.

loadTestsFromName(name, module=None)

Trả về một bộ gồm tất cả các trường hợp kiểm thử được cung cấp bởi một bộ xác định chuỗi.

Công cụ xác định name là một "tên chấm" có thể phân giải thành mô-đun, lớp trường hợp thử nghiệm, phương thức thử nghiệm trong lớp trường hợp thử nghiệm, phiên bản TestSuite hoặc đối tượng có thể gọi được trả về phiên bản TestCase hoặc TestSuite. Những kiểm tra này được áp dụng theo thứ tự được liệt kê ở đây; nghĩa là, một phương thức trên một lớp trường hợp thử nghiệm có thể sẽ được chọn là "phương thức thử nghiệm trong lớp trường hợp thử nghiệm", thay vì "một đối tượng có thể gọi được".

Ví dụ: nếu bạn có một mô-đun SampleTests chứa lớp TestCase-có nguồn gốc từ SampleTestCase với ba phương thức thử nghiệm (test_one(), test_two() và test_three()), trình xác định 'SampleTests.SampleTestCase' sẽ khiến phương thức này trả về một bộ sẽ chạy cả ba phương thức thử nghiệm. Việc sử dụng công cụ xác định 'SampleTests.SampleTestCase.test_two' sẽ khiến nó trả về một bộ thử nghiệm sẽ chỉ chạy phương thức thử nghiệm test_two(). Trình xác định có thể tham chiếu đến các mô-đun và gói chưa được nhập; chúng sẽ được nhập khẩu như một tác dụng phụ.

Phương thức này tùy chọn phân giải name liên quan đến module đã cho.

Thay đổi trong phiên bản 3.5: Nếu xảy ra ImportError hoặc AttributeError khi duyệt qua name thì một thử nghiệm tổng hợp phát sinh lỗi đó khi chạy sẽ được trả về. Những lỗi này được bao gồm trong các lỗi được tích lũy bởi self.errors.

loadTestsFromNames(names, module=None)

Tương tự như loadTestsFromName(), nhưng có một chuỗi tên chứ không phải một tên. Giá trị trả về là bộ thử nghiệm hỗ trợ tất cả các thử nghiệm được xác định cho từng tên.

getTestCaseNames(testCaseClass)

Trả về một chuỗi các tên phương thức đã được sắp xếp được tìm thấy trong testCaseClass; đây phải là lớp con của TestCase.

discover(start_dir, pattern='test*.py', top_level_dir=None)

Tìm tất cả các mô-đun kiểm tra bằng cách đệ quy vào các thư mục con từ thư mục bắt đầu được chỉ định và trả về đối tượng TestSuite chứa chúng. Chỉ các tệp kiểm tra khớp với pattern mới được tải. (Sử dụng đối sánh mẫu kiểu shell.) Chỉ những tên mô-đun có thể nhập được (tức là các mã định danh Python hợp lệ) mới được tải.

Tất cả các mô-đun thử nghiệm phải có thể nhập được từ cấp cao nhất của dự án. Nếu thư mục bắt đầu không phải là thư mục cấp cao nhất thì top_level_dir phải được chỉ định riêng.

Nếu việc nhập mô-đun không thành công, chẳng hạn như do lỗi cú pháp, thì lỗi này sẽ được ghi lại dưới dạng một lỗi duy nhất và quá trình khám phá sẽ tiếp tục. Nếu lỗi nhập là do SkipTest được nâng lên, nó sẽ được ghi là bỏ qua thay vì lỗi.

Nếu tìm thấy một gói (thư mục chứa tệp có tên __init__.py), gói đó sẽ được kiểm tra chức năng load_tests. Nếu điều này tồn tại thì nó sẽ được gọi là package.load_tests(loader, tests, pattern). Quá trình phát hiện thử nghiệm sẽ cẩn thận để đảm bảo rằng một gói chỉ được kiểm tra để kiểm tra một lần trong khi gọi, ngay cả khi chính hàm Load_tests gọi loader.discover.

Nếu load_tests tồn tại thì việc phát hiện not sẽ lặp lại vào gói, load_tests chịu trách nhiệm tải tất cả các bài kiểm tra trong gói.

Mẫu này không được lưu trữ dưới dạng thuộc tính của trình tải một cách có chủ ý để các gói có thể tiếp tục tự khám phá.

top_level_dir được lưu trữ nội bộ và được sử dụng làm mặc định cho mọi lệnh gọi lồng nhau tới discover(). Tức là, nếu load_tests của một gói gọi loader.discover() thì nó không cần phải chuyển đối số này.

start_dir có thể là tên mô-đun có dấu chấm cũng như một thư mục.

Added in version 3.2.

Thay đổi trong phiên bản 3.4: Các mô-đun tăng SkipTest khi nhập được ghi lại là bỏ qua chứ không phải lỗi.

start_dir có thể là namespace packages.

Các đường dẫn được sắp xếp trước khi được nhập để thứ tự thực hiện giống nhau ngay cả khi thứ tự của hệ thống tệp cơ bản không phụ thuộc vào tên tệp.

Thay đổi trong phiên bản 3.5: Các gói được tìm thấy hiện được kiểm tra load_tests bất kể đường dẫn của chúng có khớp với pattern hay không, vì tên gói không thể khớp với mẫu mặc định.

Thay đổi trong phiên bản 3.11: start_dir không thể là namespace packages. Nó đã bị hỏng kể từ Python 3.7 và Python 3.11 chính thức loại bỏ nó.

Thay đổi trong phiên bản 3.13: top_level_dir chỉ được lưu trữ trong suốt thời gian gọi discover.

Thay đổi trong phiên bản 3.14: start_dir một lần nữa có thể là namespace package.

Các thuộc tính sau của TestLoader có thể được định cấu hình bằng cách phân lớp hoặc gán trên một phiên bản:

testMethodPrefix

Chuỗi cung cấp tiền tố của tên phương thức sẽ được hiểu là phương thức thử nghiệm. Giá trị mặc định là 'test'.

Điều này ảnh hưởng đến getTestCaseNames() và tất cả các phương pháp loadTestsFrom*.

sortTestMethodsUsing

Hàm được sử dụng để so sánh tên phương thức khi sắp xếp chúng trong getTestCaseNames() và tất cả các phương thức loadTestsFrom*.

suiteClass

Đối tượng có thể gọi được để xây dựng bộ thử nghiệm từ danh sách các thử nghiệm. Không có phương pháp nào trên đối tượng kết quả là cần thiết. Giá trị mặc định là lớp TestSuite.

Điều này ảnh hưởng đến tất cả các phương pháp loadTestsFrom*.

testNamePatterns

Danh sách các mẫu tên thử nghiệm ký tự đại diện kiểu shell Unix mà các phương thức thử nghiệm phải khớp để được đưa vào bộ thử nghiệm (xem tùy chọn -k).

Nếu thuộc tính này không phải là None (mặc định), tất cả các phương pháp thử nghiệm được đưa vào bộ thử nghiệm phải khớp với một trong các mẫu trong danh sách này. Lưu ý rằng các kết quả khớp luôn được thực hiện bằng fnmatch.fnmatchcase(), do đó, không giống như các mẫu được chuyển đến tùy chọn -k, các mẫu chuỗi con đơn giản sẽ phải được chuyển đổi bằng ký tự đại diện *.

Điều này ảnh hưởng đến tất cả các phương pháp loadTestsFrom*.

Added in version 3.7.

class unittest.TestResult

Lớp này được sử dụng để tổng hợp thông tin về thử nghiệm nào đã thành công và thử nghiệm nào thất bại.

Đối tượng TestResult lưu trữ kết quả của một tập hợp các bài kiểm tra. Các lớp TestCase và TestSuite đảm bảo rằng kết quả được ghi lại chính xác; tác giả kiểm tra không cần phải lo lắng về việc ghi lại kết quả kiểm tra.

Các khung thử nghiệm được xây dựng dựa trên unittest có thể muốn truy cập vào đối tượng TestResult được tạo bằng cách chạy một loạt thử nghiệm cho mục đích báo cáo; một phiên bản TestResult được trả về bằng phương thức TestRunner.run() cho mục đích này.

Các phiên bản TestResult có các thuộc tính sau đây sẽ được quan tâm khi kiểm tra kết quả chạy một bộ thử nghiệm:

errors

Một danh sách chứa 2 bộ phiên bản TestCase và các chuỗi chứa các dấu vết được định dạng. Mỗi bộ dữ liệu đại diện cho một bài kiểm tra đưa ra một ngoại lệ không mong muốn.

failures

Một danh sách chứa 2 bộ phiên bản TestCase và các chuỗi chứa các dấu vết được định dạng. Mỗi bộ dữ liệu đại diện cho một thử nghiệm trong đó lỗi được báo hiệu rõ ràng bằng cách sử dụng assert* methods.

skipped

Một danh sách chứa 2 bộ phiên bản TestCase và các chuỗi chứa lý do bỏ qua bài kiểm tra.

Added in version 3.1.

expectedFailures

Một danh sách chứa 2 bộ phiên bản TestCase và các chuỗi chứa các dấu vết được định dạng. Mỗi bộ dữ liệu đại diện cho một lỗi hoặc lỗi dự kiến ​​của trường hợp kiểm thử.

unexpectedSuccesses

Danh sách chứa các phiên bản TestCase được đánh dấu là lỗi dự kiến nhưng đã thành công.

collectedDurations

Một danh sách chứa 2 bộ tên trường hợp thử nghiệm và số float biểu thị thời gian đã trôi qua của mỗi thử nghiệm được chạy.

Added in version 3.12.

shouldStop

Đặt thành True khi quá trình thực hiện kiểm tra sẽ dừng ở stop().

testsRun

Tổng số thử nghiệm chạy cho đến nay.

buffer

Nếu được đặt thành true, sys.stdout và sys.stderr sẽ được đệm ở giữa startTest() và stopTest() được gọi. Đầu ra được thu thập sẽ chỉ được lặp lại trên sys.stdout và sys.stderr thực nếu quá trình kiểm tra không thành công hoặc có lỗi. Bất kỳ đầu ra nào cũng được đính kèm với thông báo lỗi/lỗi.

Added in version 3.2.

failfast

Nếu được đặt thành true stop() sẽ được gọi khi xảy ra lỗi hoặc lỗi đầu tiên, tạm dừng quá trình chạy thử.

Added in version 3.2.

tb_locals

Nếu được đặt thành true thì các biến cục bộ sẽ được hiển thị trong truy nguyên.

Added in version 3.5.

wasSuccessful()

Trả về True nếu tất cả các lần chạy thử nghiệm cho đến nay đều đạt, nếu không thì trả về False.

Thay đổi trong phiên bản 3.4: Trả về False nếu có bất kỳ unexpectedSuccesses nào từ các thử nghiệm được đánh dấu bằng trình trang trí expectedFailure().

stop()

Phương thức này có thể được gọi để báo hiệu rằng tập hợp các thử nghiệm đang chạy sẽ bị hủy bỏ bằng cách đặt thuộc tính shouldStop thành True. Các đối tượng TestRunner phải tôn trọng cờ này và quay lại mà không chạy bất kỳ thử nghiệm bổ sung nào.

Ví dụ: tính năng này được lớp TextTestRunner sử dụng để dừng khung kiểm tra khi người dùng báo hiệu ngắt từ bàn phím. Các công cụ tương tác cung cấp triển khai TestRunner có thể sử dụng tính năng này theo cách tương tự.

Các phương pháp sau của lớp TestResult được sử dụng để duy trì cấu trúc dữ liệu nội bộ và có thể được mở rộng trong các lớp con để hỗ trợ các yêu cầu báo cáo bổ sung. Điều này đặc biệt hữu ích trong việc xây dựng các công cụ hỗ trợ báo cáo tương tác trong khi chạy thử nghiệm.

startTest(test)

Được gọi khi test case test sắp được chạy.

stopTest(test)

Được gọi sau khi trường hợp thử nghiệm test được thực thi, bất kể kết quả ra sao.

startTestRun()

Được gọi một lần trước khi bất kỳ thử nghiệm nào được thực hiện.

Added in version 3.1.

stopTestRun()

Được gọi một lần sau khi tất cả các bài kiểm tra được thực hiện.

Added in version 3.1.

addError(test, err)

Được gọi khi trường hợp thử nghiệm test đưa ra một ngoại lệ không mong muốn. err là một bộ dữ liệu có dạng được trả về bởi sys.exc_info(): (type, value, traceback).

Việc triển khai mặc định sẽ thêm một bộ (test, formatted_err) vào thuộc tính errors của cá thể, trong đó formatted_err là một truy nguyên được định dạng bắt nguồn từ err.

addFailure(test, err)

Được gọi khi test case test báo hiệu lỗi. err là một bộ dữ liệu có dạng được trả về bởi sys.exc_info(): (type, value, traceback).

Việc triển khai mặc định sẽ thêm một bộ (test, formatted_err) vào thuộc tính failures của cá thể, trong đó formatted_err là một truy nguyên được định dạng bắt nguồn từ err.

addSuccess(test)

Được gọi khi trường hợp thử nghiệm test thành công.

Việc triển khai mặc định không làm gì cả.

addSkip(test, reason)

Được gọi khi trường hợp thử nghiệm test bị bỏ qua. reason là lý do bài kiểm tra đưa ra để bỏ qua.

Việc triển khai mặc định sẽ thêm một bộ (test, reason) vào thuộc tính skipped của cá thể.

addExpectedFailure(test, err)

Được gọi khi trường hợp thử nghiệm test bị lỗi hoặc có lỗi nhưng được đánh dấu bằng trình trang trí expectedFailure().

Việc triển khai mặc định sẽ thêm một bộ (test, formatted_err) vào thuộc tính expectedFailures của cá thể, trong đó formatted_err là một truy nguyên được định dạng bắt nguồn từ err.

addUnexpectedSuccess(test)

Được gọi khi trường hợp thử nghiệm test được đánh dấu bằng trình trang trí expectedFailure() nhưng đã thành công.

Việc triển khai mặc định sẽ gắn thử nghiệm vào thuộc tính unexpectedSuccesses của phiên bản.

addSubTest(test, subtest, outcome)

Được gọi khi bài kiểm tra phụ kết thúc. test là trường hợp thử nghiệm tương ứng với phương pháp thử nghiệm. subtest là một phiên bản TestCase tùy chỉnh mô tả bài kiểm tra phụ.

Nếu outcome là None thì phép trừ đã thành công. Mặt khác, nó không thành công với một ngoại lệ trong đó outcome là một bộ dữ liệu có dạng được trả về bởi sys.exc_info(): (type, value, traceback).

Việc triển khai mặc định không làm gì khi kết quả thành công và ghi lại những thất bại nhỏ nhất như những thất bại thông thường.

Added in version 3.4.

addDuration(test, elapsed)

Được gọi khi trường hợp thử nghiệm kết thúc. elapsed là thời gian được biểu thị bằng giây và bao gồm việc thực thi các chức năng dọn dẹp.

Added in version 3.12.

class unittest.TextTestResult(stream, descriptions, verbosity, *, durations=None)

Triển khai cụ thể của TestResult được TextTestRunner sử dụng. Các lớp con nên chấp nhận **kwargs để đảm bảo tính tương thích khi giao diện thay đổi.

Added in version 3.2.

Thay đổi trong phiên bản 3.12: Đã thêm tham số từ khóa durations.

unittest.defaultTestLoader

Phiên bản của lớp TestLoader dự định được chia sẻ. Nếu không cần tùy chỉnh TestLoader, phiên bản này có thể được sử dụng thay vì liên tục tạo phiên bản mới.

class unittest.TextTestRunner(stream=None, descriptions=True, verbosity=1, failfast=False, buffer=False, resultclass=None, warnings=None, *, tb_locals=False, durations=None)

Triển khai trình chạy thử cơ bản để đưa kết quả ra luồng. Nếu stream là None thì mặc định sys.stderr được sử dụng làm luồng đầu ra. Lớp này có một số tham số có thể cấu hình được nhưng về cơ bản thì rất đơn giản. Các ứng dụng đồ họa chạy bộ thử nghiệm sẽ cung cấp các triển khai thay thế. Việc triển khai như vậy phải chấp nhận **kwargs làm giao diện để xây dựng các trình chạy thay đổi khi các tính năng được thêm vào unittest.

Theo mặc định, trình chạy này hiển thị DeprecationWarning, PendingDeprecationWarning, ResourceWarning và ImportWarning ngay cả khi chúng là ignored by default. Hành vi này có thể được ghi đè bằng cách sử dụng các tùy chọn -Wd hoặc -Wa của Python (xem Warning control) và để lại warnings cho None.

Thay đổi trong phiên bản 3.2: Đã thêm tham số warnings.

Thay đổi trong phiên bản 3.2: Luồng mặc định được đặt thành sys.stderr tại thời điểm khởi tạo thay vì thời gian nhập.

Thay đổi trong phiên bản 3.5: Đã thêm tham số tb_locals.

Thay đổi trong phiên bản 3.12: Đã thêm tham số durations.

_makeResult()

Phương thức này trả về phiên bản của TestResult được run() sử dụng. Nó không nhằm mục đích được gọi trực tiếp nhưng có thể được ghi đè trong các lớp con để cung cấp TestResult tùy chỉnh.

_makeResult() khởi tạo lớp hoặc có thể gọi được truyền trong hàm tạo TextTestRunner dưới dạng đối số resultclass. Nó mặc định là TextTestResult nếu không cung cấp resultclass. Lớp kết quả được khởi tạo với các đối số sau

luồng, mô tả, chi tiết

run(test)

Phương thức này là giao diện chung chính của TextTestRunner. Phương thức này lấy một phiên bản TestSuite hoặc TestCase. Một TestResult được tạo bằng cách gọi _makeResult() và (các) bài kiểm tra được chạy và kết quả được in ra thiết bị xuất chuẩn.

unittest.main(module='__main__', defaultTest=None, argv=None, testRunner=None, testLoader=unittest.defaultTestLoader, exit=True, verbosity=1, failfast=None, catchbreak=None, buffer=None, warnings=None)

Một chương trình dòng lệnh tải một tập hợp các bài kiểm tra từ module và chạy chúng; điều này chủ yếu là để làm cho các mô-đun thử nghiệm có thể thực thi được một cách thuận tiện. Cách sử dụng đơn giản nhất cho chức năng này là thêm dòng sau vào cuối tập lệnh kiểm tra:

nếu __name__ == '__main__':
    unittest.main()

Bạn có thể chạy thử nghiệm với thông tin chi tiết hơn bằng cách chuyển vào đối số chi tiết

nếu __name__ == '__main__':
    unittest.main(verbosity=2)

Đối số defaultTest là tên của một thử nghiệm đơn lẻ hoặc có thể lặp lại các tên thử nghiệm để chạy nếu không có tên thử nghiệm nào được chỉ định thông qua argv. Nếu không được chỉ định hoặc None và không có tên kiểm tra nào được cung cấp qua argv thì tất cả các kiểm tra tìm thấy trong module đều được chạy.

Đối số argv có thể là danh sách các tùy chọn được truyền cho chương trình, với phần tử đầu tiên là tên chương trình. Nếu không được chỉ định hoặc None, các giá trị của sys.argv sẽ được sử dụng.

Đối số testRunner có thể là lớp chạy thử nghiệm hoặc một phiên bản đã được tạo của nó. Theo mặc định, main gọi sys.exit() với mã thoát cho biết thành công (0) hoặc thất bại (1) của quá trình chạy thử nghiệm. Mã thoát là 5 cho biết không có bài kiểm tra nào được chạy hoặc bị bỏ qua.

Đối số testLoader phải là một phiên bản TestLoader và mặc định là defaultTestLoader.

main hỗ trợ việc sử dụng từ trình thông dịch tương tác bằng cách chuyển đối số exit=False. Điều này hiển thị kết quả trên đầu ra tiêu chuẩn mà không cần gọi sys.exit():

>>> từ nguồn nhập chính không đáng tin cậy nhất
>>> main(module='test_module', exit=False)

Các thông số failfast, catchbreak và buffer có tác dụng tương tự như command-line options cùng tên.

Đối số warnings chỉ định warning filter sẽ được sử dụng khi chạy thử nghiệm. Nếu không được chỉ định, nó sẽ vẫn là None nếu tùy chọn -W được chuyển cho python (xem Warning control), nếu không nó sẽ được đặt thành 'default'.

Việc gọi main sẽ trả về một đối tượng có thuộc tính result chứa kết quả của các lần chạy thử nghiệm dưới dạng unittest.TestResult.

Thay đổi trong phiên bản 3.1: Tham số exit đã được thêm vào.

Thay đổi trong phiên bản 3.2: Các thông số verbosity, failfast, catchbreak, buffer và warnings đã được thêm vào.

Thay đổi trong phiên bản 3.4: Tham số defaultTest đã được thay đổi để chấp nhận nhiều tên thử nghiệm có thể lặp lại.

Load_tests Giao thức

Added in version 3.2.

Các mô-đun hoặc gói có thể tùy chỉnh cách tải các bài kiểm tra từ chúng trong quá trình chạy kiểm tra thông thường hoặc khám phá kiểm tra bằng cách triển khai một chức năng có tên load_tests.

Nếu một mô-đun thử nghiệm xác định load_tests thì nó sẽ được gọi bởi TestLoader.loadTestsFromModule() với các đối số sau:

Load_tests(loader, Standard_tests, mẫu)

trong đó pattern được chuyển thẳng từ loadTestsFromModule. Nó mặc định là None.

Nó sẽ trả về TestSuite.

loader là phiên bản TestLoader đang tải. standard_tests là các bài kiểm tra sẽ được tải theo mặc định từ mô-đun. Thông thường, các mô-đun kiểm tra chỉ muốn thêm hoặc xóa các bài kiểm tra khỏi bộ bài kiểm tra tiêu chuẩn. Đối số thứ ba được sử dụng khi tải các gói như một phần của quá trình khám phá thử nghiệm.

Hàm load_tests điển hình tải các bài kiểm tra từ một nhóm lớp TestCase cụ thể có thể trông giống như:

test_cases = (TestCase1, TestCase2, TestCase3)

def Load_tests(trình tải, kiểm tra, mẫu):
    bộ = TestSuite()
    cho test_class trong test_case:
        kiểm tra = Loader.loadTestsFromTestCase(test_class)
        suite.addTests(kiểm tra)
    bộ trả về

Nếu quá trình khám phá được bắt đầu trong một thư mục chứa gói, từ dòng lệnh hoặc bằng cách gọi TestLoader.discover(), thì gói __init__.py sẽ được kiểm tra load_tests. Nếu chức năng đó không tồn tại, việc khám phá sẽ lặp lại vào gói như thể nó chỉ là một thư mục khác. Nếu không, việc khám phá các thử nghiệm của gói sẽ được thực hiện tối đa load_tests, được gọi với các đối số sau:

Load_tests(loader, Standard_tests, mẫu)

Điều này sẽ trả về TestSuite đại diện cho tất cả các thử nghiệm từ gói. (standard_tests sẽ chỉ chứa các bài kiểm tra được thu thập từ __init__.py.)

Vì mẫu được chuyển vào load_tests nên gói này có thể tự do tiếp tục (và có thể sửa đổi) khám phá thử nghiệm. Hàm load_tests 'không làm gì' cho gói thử nghiệm sẽ trông như sau:

def Load_tests(loader, Standard_tests, mẫu):
    Thư mục cấp # top được lưu trong bộ nhớ đệm trên phiên bản trình tải
    this_dir = os.path.dirname(__file__)
    package_tests = Loader.discover(start_dir=this_dir, mẫu=mẫu)
    Standard_tests.addTests(gói_tests)
    trả về tiêu chuẩn_tests

Thay đổi trong phiên bản 3.5: Discovery không còn kiểm tra tên gói để tìm pattern phù hợp do không thể có tên gói khớp với mẫu mặc định.

Đồ đạc lớp và mô-đun

Đồ đạc ở cấp độ lớp và mô-đun được triển khai trong TestSuite. Khi bộ kiểm tra gặp một bài kiểm tra từ một lớp mới thì tearDownClass() từ lớp trước (nếu có) sẽ được gọi, theo sau là setUpClass() từ lớp mới.

Tương tự, nếu thử nghiệm đến từ một mô-đun khác với thử nghiệm trước thì tearDownModule từ mô-đun trước sẽ được chạy, theo sau là setUpModule từ mô-đun mới.

Sau khi tất cả các bài kiểm tra đã chạy, tearDownClass và tearDownModule cuối cùng sẽ được chạy.

Lưu ý rằng các thiết bị cố định được chia sẻ không hoạt động tốt với các tính năng [tiềm năng] như song song hóa thử nghiệm và chúng phá vỡ sự cô lập thử nghiệm. Chúng nên được sử dụng cẩn thận.

Thứ tự mặc định của các bài kiểm tra được tạo bởi bộ tải kiểm tra unittest là nhóm tất cả các bài kiểm tra từ cùng một mô-đun và các lớp lại với nhau. Điều này sẽ dẫn đến việc setUpClass/setUpModule (vv) được gọi chính xác một lần cho mỗi lớp và mô-đun. Nếu bạn sắp xếp ngẫu nhiên thứ tự sao cho các bài kiểm tra từ các mô-đun và lớp khác nhau liền kề nhau thì các hàm cố định chung này có thể được gọi nhiều lần trong một lần chạy thử nghiệm.

Đồ đạc dùng chung không nhằm mục đích hoạt động với các dãy phòng có thứ tự không chuẩn. BaseTestSuite vẫn tồn tại cho các khung không muốn hỗ trợ các thiết bị dùng chung.

Nếu có bất kỳ trường hợp ngoại lệ nào xảy ra trong một trong các chức năng cố định chung thì quá trình kiểm tra sẽ được báo cáo là lỗi. Vì không có phiên bản kiểm tra tương ứng nên một đối tượng _ErrorHolder (có cùng giao diện với TestCase) được tạo để biểu thị lỗi. Nếu bạn chỉ đang sử dụng trình chạy thử nghiệm unittest tiêu chuẩn thì chi tiết này không thành vấn đề, nhưng nếu bạn là tác giả khung thì nó có thể có liên quan.

setUpClass và TearsDownClass

Chúng phải được triển khai dưới dạng các phương thức lớp

nhập khẩu đơn vị nhất

Kiểm tra lớp (unittest.TestCase):
    @classmethod
    def setUpClass(cls):
        cls._connection = createExpensiveConnectionObject()

    @classmethod
    def ripDownClass(cls):
        cls._connection.destroy()

Nếu bạn muốn setUpClass và tearDownClass trên các lớp cơ sở được gọi thì bạn phải tự mình gọi chúng. Việc triển khai trong TestCase trống.

Nếu một ngoại lệ được đưa ra trong setUpClass thì các bài kiểm tra trong lớp sẽ không chạy và tearDownClass không chạy. Các lớp bị bỏ qua sẽ không chạy setUpClass hoặc tearDownClass. Nếu ngoại lệ là ngoại lệ SkipTest thì lớp đó sẽ được báo cáo là đã bị bỏ qua thay vì có lỗi.

setUpModule và TearsDownModule

Chúng nên được thực hiện dưới dạng các chức năng:

chắc chắn setUpModule():
    tạoConnection()

def ripDownModule():
    closeConnection()

Nếu một ngoại lệ được đưa ra trong setUpModule thì không có thử nghiệm nào trong mô-đun sẽ được chạy và tearDownModule sẽ không được chạy. Nếu ngoại lệ là ngoại lệ SkipTest thì mô-đun sẽ được báo cáo là đã bị bỏ qua thay vì bị lỗi.

Để thêm mã dọn dẹp phải được chạy ngay cả trong trường hợp ngoại lệ, hãy sử dụng addModuleCleanup:

unittest.addModuleCleanup(function, /, *args, **kwargs)

Thêm một hàm được gọi sau tearDownModule() để dọn sạch các tài nguyên được sử dụng trong lớp kiểm tra. Các hàm sẽ được gọi theo thứ tự ngược lại với thứ tự chúng được thêm vào (LIFO). Chúng được gọi với bất kỳ đối số và đối số từ khóa nào được chuyển vào addModuleCleanup() khi chúng được thêm vào.

Nếu setUpModule() không thành công, nghĩa là tearDownModule() không được gọi thì mọi chức năng dọn dẹp được thêm vào sẽ vẫn được gọi.

Added in version 3.8.

unittest.enterModuleContext(cm)

Nhập context manager được cung cấp. Nếu thành công, hãy thêm phương thức __exit__() của nó làm hàm dọn dẹp bằng addModuleCleanup() và trả về kết quả của phương thức __enter__().

Added in version 3.11.

unittest.doModuleCleanups()

Hàm này được gọi vô điều kiện sau tearDownModule() hoặc sau setUpModule() nếu setUpModule() đưa ra một ngoại lệ.

Nó chịu trách nhiệm gọi tất cả các chức năng dọn dẹp được thêm bởi addModuleCleanup(). Nếu bạn cần các chức năng dọn dẹp được gọi là prior đến tearDownModule() thì bạn có thể tự gọi doModuleCleanups().

doModuleCleanups() lần lượt bật ra các phương thức khỏi ngăn xếp các hàm dọn dẹp, do đó, nó có thể được gọi bất cứ lúc nào.

Added in version 3.8.

Xử lý tín hiệu

Added in version 3.2.

Tùy chọn dòng lệnh -c/--catch để unittest, cùng với tham số catchbreak cho unittest.main(), mang đến khả năng xử lý control-C thân thiện hơn trong quá trình chạy thử. Với hành vi ngắt bắt được kích hoạt control-C sẽ cho phép thử nghiệm hiện đang chạy hoàn tất và quá trình chạy thử nghiệm sau đó sẽ kết thúc và báo cáo tất cả các kết quả cho đến nay. Control-c thứ hai sẽ tăng KeyboardInterrupt theo cách thông thường.

Trình xử lý tín hiệu xử lý control-c cố gắng duy trì khả năng tương thích với mã hoặc các thử nghiệm cài đặt trình xử lý signal.SIGINT của riêng chúng. Nếu trình xử lý unittest được gọi nhưng isn't là trình xử lý signal.SIGINT đã cài đặt, tức là nó đã được thay thế bởi hệ thống đang được kiểm tra và được ủy quyền, thì nó sẽ gọi trình xử lý mặc định. Đây thường sẽ là hành vi được mong đợi bằng mã thay thế trình xử lý đã cài đặt và ủy quyền cho nó. Đối với các thử nghiệm riêng lẻ cần tắt khả năng xử lý control-c unittest, có thể sử dụng trình trang trí removeHandler().

Có một số chức năng tiện ích dành cho tác giả khung để kích hoạt chức năng xử lý control-c trong khung kiểm tra.

unittest.installHandler()

Cài đặt trình xử lý control-c. Khi nhận được signal.SIGINT (thường là để phản hồi khi người dùng nhấn control-c), tất cả các kết quả đã đăng ký đều có stop() được gọi.

unittest.registerResult(result)

Đăng ký đối tượng TestResult để xử lý control-c. Việc đăng ký một kết quả sẽ lưu trữ một tham chiếu yếu đến kết quả đó, do đó, nó không ngăn kết quả bị thu thập rác.

Việc đăng ký một đối tượng TestResult không có tác dụng phụ nếu việc xử lý control-c không được bật, do đó, các khung kiểm tra có thể đăng ký vô điều kiện tất cả các kết quả mà chúng tạo ra một cách độc lập bất kể việc xử lý có được bật hay không.

unittest.removeResult(result)

Xóa kết quả đã đăng ký. Khi một kết quả đã bị xóa thì stop() sẽ không còn được gọi trên đối tượng kết quả đó để phản hồi lại control-c.

unittest.removeHandler(function=None)

Khi được gọi mà không có đối số, hàm này sẽ loại bỏ trình xử lý control-c nếu nó đã được cài đặt. Hàm này cũng có thể được sử dụng làm công cụ trang trí thử nghiệm để tạm thời loại bỏ trình xử lý trong khi thử nghiệm đang được thực thi

@unittest.removeHandler
def test_signal_handling(tự):
    ...