Sự khác biệt giữa setUp()và setUpClass()trong unittestkhuôn khổ Python là gì? Tại sao thiết lập sẽ được xử lý trong một phương pháp này hơn phương pháp khác?

Tôi muốn hiểu phần nào của thiết lập được thực hiện trong các chức năng setUp()và setUpClass()cũng như với tearDown()và tearDownClass().

Sự khác biệt thể hiện khi bạn có nhiều hơn một phương pháp kiểm tra trong lớp của mình. setUpClassvà tearDownClassđược chạy một lần cho cả lớp; setUpvà tearDownđược chạy trước và sau mỗi phương pháp thử nghiệm.

Ví dụ:

class Example(unittest.TestCase):
    @classmethod
    def setUpClass(cls):
        print("setUpClass")

    def setUp(self):
        print("setUp")

    def test1(self):
        print("test1")

    def test2(self):
        print("test2")

    def tearDown(self):
        print("tearDown")

    @classmethod
    def tearDownClass(cls):
        print("tearDownClass")

Khi bạn chạy thử nghiệm này, nó sẽ in:

setUpClass
setUp
test1
tearDown
.setUp
test2
tearDown
.tearDownClass

(Các dấu chấm ( .) là unittestđầu ra mặc định khi một bài kiểm tra vượt qua.) Quan sát nó setUpvà tearDownxuất hiện trước và sau test1 và test2 , trong khi setUpClassvà tearDownClasschỉ xuất hiện một lần, ở đầu và cuối của toàn bộ test case.

Sự khác biệt giữa setUp()và setUpClass()trong unittestkhuôn khổ Python là gì?

Sự khác biệt chính (như đã lưu ý trong câu trả lời của Benjamin Hodgson) là nó setUpClasschỉ được gọi một lần và đó là trước tất cả các bài kiểm tra, trong khi setUpđược gọi ngay trước mỗi và mọi bài kiểm tra. (NB: Điều tương tự cũng áp dụng cho các phương thức tương đương trong các khung thử nghiệm xUnit khác, không chỉ của Python unittest.)

Từ unittest tài liệu :

setUpClass()

Một phương thức lớp được gọi trước khi các bài kiểm tra trong một lớp riêng lẻ được chạy. 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):
    ...

và:

setUp()

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

Tại sao thiết lập sẽ được xử lý trong một phương pháp này hơn phương pháp khác?

Phần này của câu hỏi vẫn chưa được trả lời. Theo nhận xét của tôi trước câu trả lời của Gearon, setUpphương pháp này dành cho các phần tử của vật cố định phổ biến cho tất cả các bài kiểm tra (để tránh trùng lặp mã đó trong mỗi bài kiểm tra). Tôi thấy điều này thường hữu ích vì loại bỏ trùng lặp (thông thường) cải thiện khả năng đọc và giảm gánh nặng bảo trì.

Các setUpClassphương pháp là cho các yếu tố đắt tiền mà bạn thà chỉ phải làm một lần, chẳng hạn như mở một kết nối cơ sở dữ liệu, mở một tập tin tạm thời trên hệ thống tập tin, tải một thư viện chia sẻ để thử nghiệm, vv Làm những việc như vậy trước mỗi bài kiểm tra sẽ làm chậm bộ thử nghiệm quá nhiều, vì vậy chúng tôi chỉ thực hiện một lần trước tất cả các thử nghiệm. Đây là một sự suy giảm nhẹ về tính độc lập của các bài kiểm tra nhưng là một sự tối ưu hóa cần thiết trong một số tình huống. Có thể cho rằng, không nên làm những điều như vậy trong các bài kiểm tra đơn vị vì thông thường có thể giả mạo cơ sở dữ liệu / hệ thống tệp / thư viện / bất cứ thứ gì mà không sử dụng đồ thật. Như vậy, tôi thấy rằng setUpClasshiếm khi cần thiết. Tuy nhiên, nó rất hữu ích khi việc kiểm tra các ví dụ trên (hoặc tương tự) trở nên cần thiết.