The idea isn't bad, except that the performance of fixture loading is pretty terrible in general. Take a look at ticket https://code.djangoproject.com/ticket/20392 for some performance profiling and discussion.
As far as I'm concerned, using fixtures is the wrong way to populate data for tests. You're much better off creating the objects you need for each test within the test, or creating them directly inside the setUp method. You avoid the parsing and loading of json data, which is quite substantial! You could also use a third party app like factory boy to generate the data you need for each test. I think we should be encouraging this kind of design a lot more, rather than trying to optimise or push fixture loading in general. Regards, Josh On Wednesday, 3 September 2014 04:34:17 UTC+10, Matteo Kloiber wrote: > > Hello, > I thought it might be pretty helpful if there was a load_fixtures > annotation that loads fixture for a specific test method > in TransactionTestCase. On some occasions, it might be pretty hard to test > a model/view that uses only one or a few fixtures that are always the same. > Here are some occasions, where it might be helpful to have these > annotation. > > - I may want to test when the database is empty. > - It might be necessary to have a fixture with a lot of data (and I mean > >1000). Loading some much data for every testcase is highly ineffective > because it takes a time to clean up and load the data again. > > I’m sure there are more occasions when this might be helpful. > Here is what the implementation might look like: > > @load_fixtures(*fixtures, flush=False) > > fixtures are the fixtures to load (just like the instance variable). flush > means whether the old data (i.e. the data that was loaded by the instance > variable) should be flushed. `fixtures` should be optional so that flush > can sand-alone. That allows me to have an empty database (this could be > useful when only a very limited amount of tests need an empty database > while the other tests need the default fixtures). > It shouldn’t replace the fixtures instance variable, it should just be an > addition. > > I know, it can be implemented and doesn’t require changes in the core but > it would be super helpful if it came out if the box. The flush parameter > could be optimized when implementing directly in the core > (i.e. TransactionTestCase). Loading default fixtures (the ones defined in > TestCase.fixture) could be prevented this way and the tests might even run > a bit quicker. This is quicker than flushing the database/rolling back all > changes. > > Sincerely, > Matteo Kloiber > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/65066a0f-92cb-4639-88ad-c18f1b6532a7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
