Сблъсквам се със странен проблем, който изглежда идва от начина, по който модулните тестове на python управляват своя импорт и как това е свързано с макетния пакет. Това е за django проект, използващ django-nose/nose за изпълнение на тест на единица и mock за подигравка.
Имам единичен тест, използващ макет, който работи перфектно, когато се изпълнява сам (python manage.py test tests/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.
Така че изглежда има нещо, което се случва, когато всички тестове се изпълняват заедно, но не мога да разбера каква е причината за неуспеха на фалшивото инжектиране. Изглежда, че всички други модулни тестове, които използват макет, почистват след себе си (или използвайки декоратора, контекста или изричния подход на обекта на корекцията, който показвам тук).
Виждали ли сте някога нещо подобно там?
my.app.models.bookstore.BookProxy
, но кодът ви използваfrom my.app.proxies import BookProxy
. Така че е вероятно да коригирате обекти, които се оказват еднакви, когато изпълнявате тестовете ръчно, но не и когато го изпълнявате сmanage.py
. - person Simeon Visser   schedule 16.07.2014