У чому різниця між setUp()і setUpClass()в unittestфреймворці Python ? Чому налаштування обробляються одним методом над іншим?

Я хочу зрозуміти, яка частина налаштування виконується у функціях setUp()і setUpClass(), а також за допомогою tearDown()і tearDownClass().

Різниця виявляється, коли у вас є більше одного методу тестування у вашому класі. setUpClassі tearDownClassзапускаються один раз для всього класу; setUpі tearDownвиконуються до і після кожного методу випробування.

Наприклад:

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")

Коли ви запускаєте цей тест, він друкує:

setUpClass
setUp
test1
tearDown
.setUp
test2
tearDown
.tearDownClass

(Точки ( .) є unittest«и вихід з замовчуванням , коли тест пройдено) . Зауважимо , що setUpі tearDownз'являються до і після , test1 і test2 , в той час як setUpClassі tearDownClassз'являються тільки один раз, на початку і в кінці всього тесту.

У чому різниця між setUp()і setUpClass()в unittestфреймворці Python ?

Головна відмінність (як зазначено у відповіді Бенджаміна Ходжсона) полягає в тому, що setUpClassвикликається лише один раз, і це перед усіма тестами, тоді setUpяк викликається безпосередньо перед кожним тестом. (Примітка: Те саме стосується еквівалентних методів в інших тестових системах xUnit, а не тільки в Python unittest.)

З unittest документації :

setUpClass()

Метод класу, викликаний перед запуском тестів в окремому класі. setUpClass викликається з класом як єдиним аргументом і повинен бути оформлений як classmethod ():

@classmethod
def setUpClass(cls):
    ...

і:

setUp()

Метод, покликаний підготувати випробувальний прилад. Це викликається безпосередньо перед викликом методу тесту; крім AssertionError або SkipTest, будь-який виняток, викликаний цим методом, вважатиметься помилкою, а не помилкою тесту. Реалізація за замовчуванням нічого не робить.

Чому налаштування обробляються одним методом над іншим?

На цю частину запитання поки що немає відповіді. Відповідно до мого коментаря у відповідь на відповідь Gearon, setUpметод призначений для елементів кріплення, які є загальними для всіх тестів (щоб уникнути дублювання цього коду в кожному тесті). Я вважаю, що це часто корисно, оскільки видалення дублювання (як правило) покращує читабельність та зменшує навантаження на обслуговування.

setUpClassМетод для дорогих елементів , які ви хотіли б тільки зробити один раз, наприклад, відкриття з'єднання з базою даних, відкриттям тимчасового файлу в файлової системі, завантаженні поділюваних бібліотек для тестування і т.д. Робити такі речі перед кожним випробуванням буде уповільнити тестового набору занадто багато, тому ми просто робимо це один раз перед усіма тестами. Це незначне погіршення незалежності тестів, але необхідна оптимізація в деяких ситуаціях. Можна стверджувати, що не слід робити такі речі в модульних тестах, оскільки зазвичай можна знущатися над базою даних / файловою системою / бібліотекою / будь-чим, не використовуючи реальну річ. Як такий, я вважаю, що setUpClassце рідко коли потрібно. Однак корисно, коли тестування наведених вище прикладів (або подібних) стає необхідним.