On Tue, Jun 23, 2009 at 1:21 PM, Rama Vadakattu<[email protected]> wrote: > > In unit tests i need to load few fixtures i have done as below > > class TestQuestionBankViews(TestCase): > > #load this fixtures > fixtures = ['qbank',] > > def setUp(self): > login = self.client.login > (email="[email protected]",password="welcome") > > > def test_starting_an_exam_view(self): > candidate = Candidate.objects.get(email="[email protected]") > .......etc > > > def test_review_view(self): > self.assertTrue(True) > ......... > > def test_review_view2(self): > self.assertTrue(True) > ............ > > Problem: > > These fixtures are loading for every test (i.e) before > test_review_view, test_review_view2 etc... as django flushes the > database after every test > > How can i prevent that as it is taking lots of time?
> Can't i load in setUp and flush them out while exit but not between > every test and still inheriting django.test.TestCase ? No - this isn't a feature that Django has out of the box. Unit tests need to be able to guarantee the entry state of the database, and the only way to easily guarantee this is to ensure that the data is reloaded at the start of each test, which means flushing out old data before reloading. "Oh", you say. "But my test doesn't modify data! It would be ok if the database wasn't flushed!". Sure... for the moment. Then you change your implementation (on purpose or accidentally), and something strange starts happening to your tests. Tests pass or fail when they shouldn't because other tests are modifying the base data. Tests pass or fail depending on which other tests have been executed, or the order in which tests are executed. Django's test suite has repeatedly demonstrated that leaking test preconditions can be a real headache - Doctests are particularly prone to exactly this sort of problem. The sort of change you are suggesting would only serve to introduce these sorts of problems where they don't exist right now, and to introduce them into the worst possible area of the code to have surprising and unexpected results. For the record, I can think of a few ways this could be accomplished without needing changes to the Django core. However, I'm not going to document them here (or anywhere else for that matter). Without wanting to be rude - if you can't work out how to do this, then you probably shouldn't be doing it. That said, I am sensitive to the fact that Django's unit tests can take a long time to run, and that this is mostly due to the database flush. This is why Django v1.1 has modified TestCase to use transactions to optimize the test running process. This change has resulted in significantly faster test execution - in some extreme cases, up to an order of magnitude faster. If you aren't already using Django trunk, I strongly encourage you to try it out. > b.Also there should very good line of separation between > initialization of object vs initialization before every method > at present setUp method trying to do both the things As I noted earlier, each test case needs to be isolated. Setting up database data is one of the conditions that needs to be guaranteed. The distinction you are pointing to only exists in your imagination. Completely aside from any feature of Django - there is a very good reason why setUp and tearDown are run before and after each test, but there is no equivalent method for the start and end of execution for an entire TestCase. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
