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):
# A custom method that retrieves some set of DefaultThing
# objects. This doesn't override any Manager methods.
# 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):
# Overridden to work with the OtherThing class.
# 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
# This is my attempt to Fake a Model.
class M(Model):objects = DefaultThingManager()
self.M = M
# 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.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 M(Model):objects = OtherThingManager()
self.M = M
# 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
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 O(Model): # O for "Other" instead of "M" for Modelobjects = OtherThingManager()
self.O = O
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
self.objects = OtherThingManager() # This doesn't have to be attached to a Model
Lesson learned? Unless you absolutely need a model, don't make things harder than they need to be!
本文开发（python）相关术语:python基础教程 python多线程 web开发工程师 软件开发工程师 软件开发流程