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