Я столкнулся со странной проблемой, которая, кажется, возникает из-за того, как модульные тесты Python управляют своим импортом и как это связано с фиктивным пакетом. Это для проекта django, использующего django-nose/nose для запуска модульного теста и mock для насмешек.
У меня есть модульный тест с использованием макета, который отлично работает при запуске в одиночку (тестовые тесты python manage.py/test_code.py)
внутри test_code.py:
from my.app.models.bookstore import create_from_proxy
class MockTestCase( TestCase ):
def setUp( self ):
self.patcher = patch( 'my.app.models.bookstore.BookProxy', autospec=True )
self.mock_proxy = self.patcher.start()
self.proxy_instance = self.mock_proxy.return_value
self.proxy_instance.json = json.loads(BOOK_JSON)
def tearDown( self ):
self.patcher.stop()
def test_mock_works( self ):
book_id = 55
v = create_from_proxy( book_id )
self.assertTrue( self.mock_proxy.called )
... more tests ...
внутри bookstore.py:
from my.app.proxies import BookProxy
def create_from_proxy( self, id ):
proxy = BookProxy(id)
...
Однако, когда я запускаю этот тест как часть всего набора тестов (тест python manage.py), тест терпит неудачу, потому что код bookstore.py не вводит фиктивный класс и возвращается к фактическому коду для BookProxy.
Таким образом, кажется, что происходит что-то с состоянием, когда все тесты выполняются вместе, но я не могу понять, что вызывает сбой фиктивной инъекции. Другие модульные тесты, использующие mock all, похоже, убирают за собой (используя либо декоратор, либо контекст, либо подход с явным патч-объектом, который я показываю здесь).
Что-то подобное когда-нибудь видели там раньше?
my.app.models.bookstore.BookProxy
, но ваш код используетfrom my.app.proxies import BookProxy
. Таким образом, вы, вероятно, исправляете объекты, которые оказались одинаковыми при запуске тестов вручную, но не при запуске с помощьюmanage.py
. - person Simeon Visser   schedule 16.07.2014