-1

Я пишу интеграционные тесты, используя простой unittest в Python (import unittest) и создаю заглушки для некоторых внешних сервисов. Теперь я хочу запустить те же тесты с реальной реализацией; но и сохранить заглушки. Таким образом, я могу запускать тесты с и без окурков и сравнивать поведение.Настройка среды для тестирования в Python

Я выполняю свои тесты как с SetupTools, так и с помощью PyCharm. Есть ли какой-то общий способ для меня установить/вставить/загрузочный параметр, который говорит моему коду, чтобы использовать заглушку или реальную реализацию? Командная строка предпочтительна. Любые указатели оценили. :)

+1

unittests не должны использовать реальную реализацию. если бы они это сделали, они были бы интеграционными тестами. сделайте separete тесты, которые используют реальную реализацию. –

+0

Я просто использую библиотеку unittest, но вы правы, что это интеграционные тесты. Независимо: я хотел бы иметь возможность реализовать как реальную реализацию, так и заглушку. Это сравнение дало мне большую ценность раньше, когда что-то внешнее изменение. –

+0

Скажите, что вы тестируете устройство под названием 'foo'. Это устройство использует реальную реализацию 'bar'. Бар имеет опечатку и выдает ошибку. Ваш юнит-тест для 'foo' не будет выполнен, даже если блок' foo' не имеет ошибки. Вот почему нецелесообразно использовать реальные реализации в модульных тестах, и я думаю, вы должны пересмотреть подход. –

ответ

0

Похоже, что вы ищете mocking framework. Mocking frameworks позволяют вам создать «заглушку» для метода из вашего теста. Это хорошо, потому что вы не хотите вставлять какой-либо конкретный код в свой фактический код.

Одним из наиболее популярных рамок Mocking для питона 2. * является python-mock (на самом деле это идет с Python 3) Таким образом, вы можете написать код, как:

from mock import MagicMock 

test_foo_mocked(): 
    bar = MagicMock() 
    bar.return_value = 'fake_val' 
    assertEqual(bar(), 'fake_val') 

test_foo_real(): 
    assertEqual(bar(), 'real_val') 

Side Примечание:
Я действительно рекомендуйте, чтобы вы рассматривали их как совершенно несвязанные тесты. Существует множество преимуществ для того, чтобы ваши интеграционные тесты были отделены от ваших модульных тестов. Размышление о них как о двух разных способах запуска «одного теста» может побудить вас писать плохие тесты. Модульные тесты должны иметь возможность проверять те, которые трудно или невозможно протестировать с помощью интеграционных тестов и наоборот.

+0

Спасибо за указатели, но я стараюсь держаться подальше от Mocking как можно больше. Тем не менее, у меня есть заглушки, которые действительно не нуждаются в инфраструктуре в Python. Хотя я вижу, что вы можете получить некоторые уродливые тесты, рассматривая их как один, вам также придется обновлять несколько тестов, когда что-то изменится. Таким образом, вы можете оказаться в ситуации, когда тест real-impl обновляется, а тест-заглушка работает против чего-то, что не происходит в реальном имплеуме. –

Смежные вопросы