On Mon, Jul 4, 2011 at 8:54 AM, Jim Dalton <jim.dal...@gmail.com> wrote: > I've created a ticket for this and uploaded a patch: > https://code.djangoproject.com/ticket/16401 > Please feel free to review and let me know if this is a good idea in the > first place, as well as if the patch makes sense and is the right approach.
Hm. While I think the feature's a good idea (I've been stung by tests running against a live cache) I can't say I'm particularly thrilled by the approach here. Monkeypatching is acceptable in situations like these, but there's a limit... and I think patching five methods is starting to reach it. Remember: as much as possible, tests should operate just like production. Any difference, no matter how small, introduces the worst kind of bugs: ones that only show up in production. I have an alternate proposal: Instead of using the default cache defined in CACHES, use a "test cache." This can safely be flushed, meaning that no monkeypatching is needed. The added benefit here is that this works similarly to the database engine, so it'll be fairly easy to understand. Now, unlike DB test we can't just prefix "test_" to the database name (because we haven't got one), nor can we prefix keys (because not all cache backends can do something like "delete test:*"). So I'd suggest we look for a "test" backend defined in CACHES and fall back to a local memory cache if not defined. I think this simplifies things immensely, and also gives a fair bit of control -- if I want to test against a real cache backend, I just define CACHES['test'] and roll. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
