On Fri, Jul 1, 2011 at 10:54 AM, Jim D. <jim.dal...@gmail.com> wrote:
> This issue came up again for me recently: Because the cache is not reset or
> flushed after every test, cache values linger there. This can create
> headaches when writing tests.
> I would like to propose that we treat the cache backend(s) like database
> backends during the test run. Specifically, I propose that we:
> * Prefix "test_" before the KEY_PREFIX in each backend during global setup.
> This is equivalent to adding the test_ prefix to DB names. In doing this we
> prevent cache calls during test form overwriting possible legitimate values.
> * Monkey patch cache.set() (and cache.set_many()) such that we record all
> keys used to set values during a test.
> * Use cache.delete_many() on the list of keys we record being set during
> test teardown. This will restore the cache to its previous state after each
> test run. It's better than flush() which clears the whole cache and is too
> destructive to be run during testing.
> I don't think it needs to be more complicated than this.

Well, I think you forgot all the other low-level cache options, like
.incr, .add, etc.?

If I were to do this, I wouldn't have cache shared between tests or
environments, so I'd be tempted to use flush.

Rather than "test_" and bookkeeping on key names, the key prefix was
the hostname + timestamp from the beginning of the run, so that test
keys would never collide?

Or, what if we just had hooks called from setUp and tearDown, either
NotImplemented methods, or signals?

Book-keeping with monkey-patched methods sounds fiddly to me; consider
the case where celery pokes keys in, but our bookkeeping doesn't know
about it?

-- 
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.

Reply via email to