Хто-небудь може пояснити використання Python setUpі tearDownметодів під час написання тестових кейсів, крім того, що setUpвикликається безпосередньо перед викликом тестового методу і tearDownвикликається відразу після його виклику ?
Відповіді:
Загалом, ви додаєте всі необхідні кроки до setUp і всі кроки до очищення до tearDown.
Більше з прикладами можна прочитати тут .
Коли визначено метод setUp (), тест-драйвер буде запускати цей метод перед кожним тестом. Подібним чином, якщо визначено метод tearDown (), тестовий виконавець буде викликати цей метод після кожного тесту.
Наприклад, у вас є тест, який вимагає існування елементів або певного стану, тож ви вкладаєте ці дії (створення екземплярів об'єктів, ініціалізація db, підготовка правил тощо) у setUp.
Окрім того, як ви знаєте, кожен тест повинен зупинятися там, де його було запущено - це означає, що нам потрібно відновити стан програми до початкового стану - наприклад, закрити файли, з’єднання, видалити щойно створені елементи, викликати зворотний виклик транзакцій тощо - все це кроки повинні бути включені в tearDown.
Отже, ідея полягає в тому, що сам тест повинен містити лише ті дії, які потрібно виконати з тестовим об’єктом для отримання результату, тоді як setUp і tearDown - це методи, які допоможуть вам залишити тестовий код чистим та гнучким.
Ви можете створити setUp і tearDown для цілої низки тестів і визначити їх у батьківському класі - так вам було б легко підтримувати такі тести та оновлювати типові підготовки та очищення.
Якщо ви шукаєте простий приклад, використовуйте наступне посилання з прикладом
Ви можете використовувати їх для виділення коду, загального для всіх тестів у наборі тестів.
Якщо у вас багато повторюваних кодів у ваших тестах, ви можете скоротити їх, перемістивши цей код у setUp / tearDown.
Ви можете використовувати це для створення тестових даних (наприклад, налаштування підробок / знущань) або вимкнення функцій підробками.
Якщо ви проводите інтеграційне тестування, ви можете використовувати перевірку попередніх умов середовища в setUp і пропустити тест, якщо щось не налаштовано належним чином.
Наприклад:
class TurretTest(unittest.TestCase):
def setUp(self):
self.turret_factory = TurretFactory()
self.turret = self.turret_factory.CreateTurret()
def test_turret_is_on_by_default(self):
self.assertEquals(True, self.turret.is_on())
def test_turret_turns_can_be_turned_off(self):
self.turret.turn_off()
self.assertEquals(False, self.turret.is_on())Припустимо, у вас є набір з 10 тестами. 8 тестів мають однаковий код налаштування / відключення. Інші 2 - ні.
setup та teardown дають вам хороший спосіб рефакторингу цих 8 тестів. Тепер, що ви робите з іншими 2 тестами? Ви перенесли б їх до іншого тестового корпусу / набору. Тож використання налаштування та розірвання також допомагає дати природний спосіб розбити тести на кейси / набори