> > I believe as a general principle that a testing framework should always > return the system under test to the state it was in prior to the run. > Calling cache.flush() violates that principle -- and of principle concern to > me, it flushes your *entire* cache. That means if someone executed tests in > production it could kill an entire cache, a situation which could be > slightly annoying or a horrific headache depending. > > Of course, if no one else agrees with me that this is a worthy principle > for Django tests then I won't waste anyone's time by undertaking a patch :)
I'd like to +1 on the whole idea. Making the testing framework use a special key prefix when saving/getting values from cache during test run (a key prefix such as "test_", which is equivalent to adding the "test_" prefix for DB names, as pointed out by Jim) and reset all records saved in cache during test run would not only ensure that tests are not polluting "real cache" with dummy values and are not altering legitimate values in cache, it would also ensure that tests are run within a pristine cache. That is, it would prevent tests from interacting with some cache values which would have been saved outside the test run (during normal system run or during a previous test run, for instance), i.e. it would prevent tests from being sensitive to cache state. -- 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.
