Opened 10 years ago
Closed 10 years ago
#23289 closed New feature (fixed)
Make mock library available for testing in Django
Reported by: | Claude Paroz | Owned by: | Tim Graham |
---|---|---|---|
Component: | Testing framework | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Tim Graham | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
This question was raised while working on #21523.
unittest.mock
is available in Python 3.3+. Backports for previous Python versions are available from https://pypi.python.org/pypi/mock.
Basically the main options are:
- Vendor the mock library backport in Django and conditionally import that backport (we used to have that for unittest2).
- Use a strategy similar to the
selenium
dependency, that is having a test class or a mixin class explicitly used when we are usingmock
functionality in a test, and that class would skip the test whenmock
is not available.
- Have the
mock
library as a hard dependency for our test suite, checking its availability inruntests.py
for Python < 3.3 with an appropriate message.
Change History (8)
comment:2 by , 10 years ago
mock
's utility goes beyond its potential usage in the mentioned ticket. It might certainly be useful in several other cases in the current Django test suite.
I've purposefully refrained from giving any personal preference in the ticket description, but experience has told us that vendoring should be a last-resort solution. My preference goes to 3., while 2. might be interesting in the sense that it might be useful for some external reusable Django apps.
comment:3 by , 10 years ago
I think it's great that you can just download Django and ./runtests.py
works. I know pip and venv have made dependencies much easier, but I think there are still some really great benefits to making dependencies as optional as possible. I'm new to testing in general: is it too hard to manually patch things to make a mock by hand?
comment:4 by , 10 years ago
Cc: | added |
---|---|
Triage Stage: | Unreviewed → Accepted |
Undecided on the approach, but definitely would like this.
comment:5 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:6 by , 10 years ago
Has patch: | set |
---|
PR is ready for review. I only updated one place to use mock, I'm sure there are others that could make use of it, but I'll create a separate ticket to audit for them after this goes in.
comment:7 by , 10 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
comment:8 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I assume it's not possible or extremely complicated to write the test without mock? It would be great if the tests just worked. It seems to me vendoring the library like unittest2 is our best option, if we use mock at all. It has the benefit of reliably providing the library to users, though removes some incentive to upgrade to python 3.