Didn't know that was even possible. I'll try that. I think I want the cache to work in the tests. Otherwise they wouldn't test the cache. Best would be if I could delete everything from the cache before the tests begin.
You can monkey patch your cache settings in your test module. Stick this on the top of your test module:
from django.conf import settings
settings.CACHE_BACKEND = 'dummy:///'
A better solution is to have a dev settings module that has no cache and a production settings module that does have cache.
When it comes to caching I like abstracting the "if whatever is None" to a decorator so that it can be reused.
For instance that decorator could be like this: http://www.djangosnippets.org/snippets/1237/
That way you don't have to worry about the cache being a factor in your tests when it's disabled because you can set up a unittest to test the decorator in isolation and can assume it's functioning correctly in any dependent code.
Yeah that's why I like to abstract the cache functionality out of the function. That way you can test the functionality without caching and test the caching mechanism in two seperate tests.
That way you can reuse the decorator and rest assured that any function that uses it will cache correctly.
The code above was a simple example, it won't work with dynamic cache keys but I'm sure you could figure out a more complex decorator if you need it.
All good stuff. I'm going to use your little decorator tip too to clean up my code and use locmem (as Stas Shtin pointed out) as the backend. That way cache does come into play in the tests too but reset each time I start the testrunner.
Comment
Didn't know that was even possible. I'll try that.
I think I want the cache to work in the tests. Otherwise they wouldn't test the cache.
Best would be if I could delete everything from the cache before the tests begin.
Parent comment
You can monkey patch your cache settings in your test module. Stick this on the top of your test module: from django.conf import settings settings.CACHE_BACKEND = 'dummy:///' A better solution is to have a dev settings module that has no cache and a production settings module that does have cache. When it comes to caching I like abstracting the "if whatever is None" to a decorator so that it can be reused. For instance that decorator could be like this: http://www.djangosnippets.org/snippets/1237/ That way you don't have to worry about the cache being a factor in your tests when it's disabled because you can set up a unittest to test the decorator in isolation and can assume it's functioning correctly in any dependent code.
Replies
Yeah that's why I like to abstract the cache functionality out of the function. That way you can test the functionality without caching and test the caching mechanism in two seperate tests.
That way you can reuse the decorator and rest assured that any function that uses it will cache correctly.
The code above was a simple example, it won't work with dynamic cache keys but I'm sure you could figure out a more complex decorator if you need it.
All good stuff. I'm going to use your little decorator tip too to clean up my code and use locmem (as Stas Shtin pointed out) as the backend. That way cache does come into play in the tests too but reset each time I start the testrunner.