A long time ago (django 1.3 era) I wrote a library (no need to change
django) to do exactly this, using savepoints to rollback:
https://github.com/machinalis/django-fasttest
It worked pretty well for a large project and provided a large speedup (i
think it was about 5x) on a large test suite. But
Data migrations are kind of separate to the per-test fixtures; one is
"initial data" shared between testing and production, and one is
test-specific code. #22487 was just to emulate database rollback on
backends that don't have transactions, since we can no longer emulate it
using "flush; loaddata
Yeah as said that ticket resolved the issue that you can't test data
migrations, so for now on you could use data migrations and test them.
And I think one of the things we should definitly do is a guide for
migrating fixtures to data migrations and work towards that path instead of
fixing beha
That ticket seems to address issues with initial_data and not necessarily
deal with fixtures that are loaded for a specific TestCase. I do agree that
we should encourage people to not use fixtures and build their test data
within the scope of the test or the TestCase.
Regards,
Michael manfre
On
Just a quick question regarding to these posts / tickets.
In the last few weeks we fixed: https://code.djangoproject.com/ticket/22487
So I think that we now don't need to rely on fixtures and should just tell
the people to use that behavior in the first place.
I mean I'm not a Django core develop
manfre was nice enough to test this patch out on mssql for me. The subset
of tests that use fixtures went from 385 seconds to 158 seconds (+2
failures). The improvement seems to be stable across backends, but isn't
very significant when considering the entire test suite.
I'm going to abandon th
I used the patch in the above ticket as a base, and implemented fixture
loading in the setUpClass classmethod rather than the setUp method. I found
that it improved the total running time of the entire test suite by about
10%, but it improved TestCases that use fixtures by a factor of 3.
https:
In fact, I just reinvented https://code.djangoproject.com/ticket/20392.
The patch on that ticket is pretty good, I'll try to review it again.
--
Aymeric.
On 7 juin 2014, at 10:12, Aymeric Augustin
wrote:
> Hi Josh,
>
> Fixtures don't receive a lot of attention because they're hard to main
Hi Josh,
Fixtures don't receive a lot of attention because they're hard to maintain and
generally inferior to object generators such as factory_boy. Still, it would be
good to optimize them.
On 7 juin 2014, at 09:34, Josh Smeaton wrote:
> I've been looking into the django testing infrastructu
I've been looking into the django testing infrastructure today to see if
there was any particular reason why the test suite takes so long to run.
Mainly, I didn't understand why fixtures are loaded for every single test
method. To be honest, I didn't think fixtures were loaded for every test
me
10 matches
Mail list logo
