未加星标

Django Manager Testing Woes

字体大小 | |
[开发(python) 所属分类 开发(python) | 发布者 店小二03 | 时间 2016 | 作者 红领巾 ] 0人收藏点击收藏

I've recently run into some strange behavior while testing some custom Django managers. While, I can't list all of the exact code (it's not open source), I'll try to list some simple examples that illustrate the problem so (hopefully), this post will be helpful for others.

To get started, assume I have the following Model and Manager:

class DefaultThingManager(models.Manager):
def things():
# A custom method that retrieves some set of DefaultThing
# objects. This doesn't override any Manager methods.
class DefaultThing(Model):
# Some fields.
objects = DefaultThingManager()

I've also got some other Manager and Model. Note that this model inherits from DefaultThingManager (there's some other behavior we want from that class).

class OtherThingManager(DefaultThingManager):
def things():
# Overridden to work with the OtherThing class.
class OtherThing(Model):
# Some fields.
objects = OtherThingManager()

So, that's really the gist of the models and managers. The managers don't really do anything unusual, but I wanted to write unit tests for them, so I created a test case that looks something like this:

# defined in tests/defaultthingmanager.py
class TestDefaultThingManager(TestCase):
def setUp(self):
# This is my attempt to Fake a Model.
class M(Model):objects = DefaultThingManager()
self.M = M
self.assertIsInstance(self.M.objects, DefaultThingManager)
def test_things(self):
# Heavily uses Mock to test stuff... eg, to test that the method
# filtered something correctly, I do stuff like this:
_f = self.M.objects.filter
self.M.objects.filter = Mock()
self.M.objects.things()
self.M.objects.filter.assert_has_calls([# check for stuff here...
])
self.M.objects.filter = _f

Now, to test the OtherThingManager , I created a similar test case

# defined in tests/otherthingmanager.py
class TestOtherThingManager(TestCase):
def setUp(self):
class M(Model):objects = OtherThingManager()
self.M = M
self.assertIsInstance(self.M.objects, OtherThingManager)
def test_things(self):
# Similar to above

This is where things get a little confusing. While writing these test cases, I'd run tests restricting them to the test case or the individual test, like so:

python manage.py test myapp.TestOtherThingManager

or:

python manage.py test myapp.TestOtherThingManager.test_things

Doing this, all worked as expected. However, when I ran the full test suite for an app, my TestOtherThingManager case would start failing. For some reason, the fake class's manager was an instance of DefaultThingManager instead of TestOtherThingManager !

======================================================================
ERROR: test_things (myapp.tests.otherthingmanager.TestOtherThingManager)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/brad/django/myproject/myapp/tests/managers/otherthingmanager.py", line 25, in setUp
self.assertIsInstance(self.M.objects, OtherThingManager)
AssertionError: <myapp.models.DefaultThingManager object at 0x10ae80ed0> is not an instance of <class 'myapp.models.OtherThingManager'>

Now this really made me scratch my head (as well as mutter a few choice words under my breath). I still don't know why this happened, but here's how I fixed it.

Remember that fake Model class in setUp ? It's now named something different in each TestCase.

# tests/otherthingmanager.py
class TestOtherThingManager(TestCase):
def setUp(self):
class O(Model): # O for "Other" instead of "M" for Modelobjects = OtherThingManager()
self.O = O
self.assertIsInstance(self.O.objects, OtherThingManager)

Now that the fake Model class has a unique name, all tests pass when run individually or during a full test suite.

Unfortunately, I don't know whether or not I should blame Mock (it does magic things at the module, level, right?) or if there's something going on behind the scenes with Django's test suite that I don't understand. I'm happy my tests run (100% coverage!), but I've still got a fairly significant uneasy feeling about all of this.

I'm certain that my method of faking a Model class in setUp is probably the real culprit, here, and I'd love to have someone enlighten me!

Thanks for reading this far!

UPDATE:There's absolutely no reason why you can't just instantiate an ModelManager by itself. For example:

# tests/otherthingmanager.py
class TestOtherThingManager(TestCase):
def setUp(self):
self.objects = OtherThingManager() # This doesn't have to be attached to a Model
self.assertIsInstance(self.objects, OtherThingManager)

Lesson learned? Unless you absolutely need a model, don't make things harder than they need to be!

本文开发(python)相关术语:python基础教程 python多线程 web开发工程师 软件开发工程师 软件开发流程

主题: Django
分页:12
转载请注明
本文标题:Django Manager Testing Woes
本站链接:http://www.codesec.net/view/483234.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 开发(python) | 评论(0) | 阅读(35)