Very well explained. Thanks Russell Keith-Magee
On Jun 23, 4:58 am, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:
> On Tue, Jun 23, 2009 at 1:21 PM, Rama Vadakattu<rama.vadaka...@gmail.com>
> 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="m...@gmail.com",password="welcome")
>
> > def test_starting_an_exam_view(self):
> > candidate = Candidate.objects.get(email="m...@gmail.com")
> > .......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 %-)- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
