Resetting settings under test
In general, the TestCase does a good job of cleaning up the environment (resetting the DB, etc.), but I've run across an edge case that might be worth putting upstream. I have a large codebase running multi-tenant -- lots of sites per WSGI process, running process-per-request, and it serves those sites by mutating settings per request (via middleware), including poking an urlconf onto the request. Under test, this leaves these fairly weird, since the settings mutations can affect other test cases. I realize that in general, settings are intended to be immutable, but... what do you think of TestCase tearDown restoring the settings as they were before the test runs? -- 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.
Re: Resetting settings under test
On May 13, 3:41 pm, Jeremy Dunck wrote: > In general, the TestCase does a good job of cleaning up the > environment (resetting the DB, etc.), but I've run across an edge case > that might be worth putting upstream. > > I have a large codebase running multi-tenant -- lots of sites per WSGI > process, running process-per-request, and it serves those sites by > mutating settings per request (via middleware), including poking an > urlconf onto the request. > > Under test, this leaves these fairly weird, since the settings > mutations can affect other test cases. > > I realize that in general, settings are intended to be immutable, > but... what do you think of TestCase tearDown restoring the settings > as they were before the test runs? The tearDown should also handle reset of cached settings. There are a few, at least translations __init__.py and localization have caches that need resetting. It would be good if settings had a method "reset" which would restore the original settings and clear the caches. A complete API of change_setting, restore_setting and reset_all would be even better. - Anssi -- 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.
Re: Resetting settings under test
On 13.05.2011, at 15:52, akaariai wrote: > On May 13, 3:41 pm, Jeremy Dunck wrote: >> In general, the TestCase does a good job of cleaning up the >> environment (resetting the DB, etc.), but I've run across an edge case >> that might be worth putting upstream. >> >> I have a large codebase running multi-tenant -- lots of sites per WSGI >> process, running process-per-request, and it serves those sites by >> mutating settings per request (via middleware), including poking an >> urlconf onto the request. >> >> Under test, this leaves these fairly weird, since the settings >> mutations can affect other test cases. >> >> I realize that in general, settings are intended to be immutable, >> but... what do you think of TestCase tearDown restoring the settings >> as they were before the test runs? > > The tearDown should also handle reset of cached settings. There are a > few, at least translations __init__.py and localization have caches > that need resetting. It would be good if settings had a method "reset" > which would restore the original settings and clear the caches. A > complete API of change_setting, restore_setting and reset_all would be > even better. I've added something related the other day in changeset 16165. Jannis -- 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.
Re: RFC: Composite fields API
I'm not that familiar with GFK's and how they work in django, but I just wanted to check... Will we have (non-generic) FK support for this, or is that another can-o-worms that won't get touched for some time? Regards, Owen -- 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.
[GSoC form rendering] Weekly check-in -1.0
Hi,
I used the last week to setup the 'test environment' for proof-of-concept'ing
the API we will be implementing. The first thing there is that I setup a (yet)
simplistic template for
1. the form tag, the monolithic approach how I have proposed it
2. multiple tags like proposed by Russell.
Both can be found in the form-rendering-api repo on github [1 & 2].
Feel free to fork the repo, adding more of these proposals or changing the API
of already proposed syntaxes.
The other thing I did was a quick proof-of-concept of the idea that came up
for a revised media handling. The problem with media handling is, that there
might arise the need in the middle of the template to inject some CSS
definitions in the head of the page. It turned out that this can be done with
the current template engine. See the github repo for implementation details
[3]. It also contains tests where you can see the tag in action.
Here a short teaser for the {% media %} tag::
{% load media_tags %}
{% media "css" %}
{% addmedia "css" %}
p { color: #ff; }
{% endaddmedia %}
This text will be red.
... will render to ... ::
p { color: #ff; }
This text will be red.
| [1]
https://github.com/gregmuellegger/django-form-rendering-api/blob/master/formapi/templates/api_samples/single_tag.html
| [2]
https://github.com/gregmuellegger/django-form-rendering-api/blob/master/formapi/templates/api_samples/modifier_tags.html
| [3]
https://github.com/gregmuellegger/django-form-rendering-api/blob/master/formapi/media_framework/templatetags/media_tags.py
--
Servus,
Gregor Müllegger
--
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.
Re: DecimalField allows float value as 'default'.
http://code.djangoproject.com/ticket/16015 I've uploaded a patch, but changed the status to 'Design Decision Needed' from 'Accepted.' The problem is that although my patch follows the existing convention and results in passing tests in Python 2.6, the Python core developers have made an important change to the way Decimal objects work -- they may now be instantiated with floats. This means that my patch introduces a failing test if Python 2.7 is being used. The patch: http://code.djangoproject.com/attachment/ticket/16015/16015_DecimalField_invalid_defaults.diff As I mentioned in the comment I just added to the ticket, the current "bug" is more pedantry than something that causes errors for real users. So, I leave it to the core devs to suggest an improved patch method or marking it wontfix. Thanks, Shawn -- 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.
Test optimizations (2-5x as fast)
tl;dr: I've written an alternative TestCase base class which makes fixture-using tests much more I/O efficient on transactional DBs, and I'd like to upstream it. Greetings, all! This is my first django-dev post, so please be gentle. :-) I hack on support.mozilla.com, a fairly large Django site with about 1000 tests. Those tests make heavy use of fixtures and, as a result, used to take over 5 minutes to run. So, I spent a few days seeing if I could cut the amount of DB I/O needed. Ultimately, I got the run down to just over 1 minute, and almost all of those gains are translatable to any Django site running against a transactional DB. No changes to the apps themselves are needed. I'd love to push some of this work upstream, if there's interest (or even lack of opposition ;-)). The speedups came from 3 main optimizations: 1. Class-level fixture setup Given a transaction DB, there's no reason to reload fixtures via dozens of SQL statements before every test. I made use of setup_class() and teardown_class() (yay, unittest2!) to change the flow for TestCase-using tests to this: a. Load the fixtures at the top of the class, and commit. b. Run a test. c. Roll back, returning to pristine fixtures. Go back to step b. d. At class teardown, figure out which tables the fixtures loaded into, and expressly clear out what was added. Before this optimization: 302s to run the suite After: 97s. Before: 37,583 queries After: 4,116 On top of that, an additional 4s was saved by reusing a single connection rather than opening and closing them all the time, bringing the final number down to 93s. (We can get away with this because we're committing any on-cursor-initialization setup, whereas the old TestCase rolled it back.) Here's the code: https://github.com/erikrose/test-utils/blob/master/test_utils/__init__.py#L121. I'd love to generalize it a bit (to fall back to the old behavior with non-transactional backends, for example) and offer it as a patch to Django proper, replacing TestCase. Thoughts? (If you notice that copy-and-paste of loaddata sitting off to the side in another module, don't fret; in the patch, that would turn into a refactoring of loaddata to make the computation of the fixture-referenced tables separately reusable.) 2. Fixture grouping I next observed that many test classes reused the same sets of fixtures, often via subclassing. After the previous optimization, our tests still loaded fixtures 114 times, even though there were only 11 distinct sets of them. So, I thought: why not write a custom testrunner that buckets the classes by fixture set and advises the classes that, unless they're the first or last in a bucket, they shouldn't bother tearing down or setting up the fixtures, respectively? This took the form of a custom nose plugin (we use nose for all our Django stuff), and it took another quarter off the test run: Before: 97s After: 74s Of course, test independence is still preserved. We're just factoring out pointlessly repeated setup. I don't really have plans to upstream this unless someone calls for it, but I'll be making it available soon, likely as part of django-nose. 3. Startup optimizations At this point, it was bothering me that, just to run a single test, I had to wait through 15s of DB initialization (mostly auth_permissions and django_content_type population)—stuff which was already perfectly valid from the previous test run. So, building on some work we had already done in this direction, I decided to skip the teardown of the test DB and, symmetrically, the setup on future runs. If you make schema changes, just set an env var, and it wipes and remakes the DB like usual. I could see pushing this into django-nose as well, but it's got the hackiest implementation and can potentially confuse users. I mention it for completeness. Before: startup time 15s After: 3s (There's quite a wide variance due to I/O caching luck.) Code: https://github.com/erikrose/test-utils/commit/b95a1b7 If you read this far, you get a cookie! I welcome your feedback on merging optimization #1 into core, as well as any accusations of insanity re: #2 and #3. FWIW, everything works great without touching any of the tests on 3 of our Django sites, totaling over 2000 tests. Best regards and wishes for a happy weekend, Erik Rose support.mozilla.com -- 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.
Re: Test optimizations (2-5x as fast)
On Fri, May 13, 2011 at 6:57 PM, Erik Rose wrote: > tl;dr: I've written an alternative TestCase base class which makes > fixture-using tests much more I/O efficient on transactional DBs, and I'd > like to upstream it. > > Greetings, all! This is my first django-dev post, so please be gentle. :-) > I hack on support.mozilla.com, a fairly large Django site with about 1000 > tests. Those tests make heavy use of fixtures and, as a result, used to take > over 5 minutes to run. So, I spent a few days seeing if I could cut the > amount of DB I/O needed. Ultimately, I got the run down to just over 1 > minute, and almost all of those gains are translatable to any Django site > running against a transactional DB. No changes to the apps themselves are > needed. I'd love to push some of this work upstream, if there's interest (or > even lack of opposition ;-)). > > The speedups came from 3 main optimizations: > > 1. Class-level fixture setup > > Given a transaction DB, there's no reason to reload fixtures via dozens of > SQL statements before every test. I made use of setup_class() and > teardown_class() (yay, unittest2!) to change the flow for TestCase-using > tests to this: >a. Load the fixtures at the top of the class, and commit. >b. Run a test. >c. Roll back, returning to pristine fixtures. Go back to step b. >d. At class teardown, figure out which tables the fixtures loaded into, > and expressly clear out what was added. > > Before this optimization: 302s to run the suite > After: 97s. > > Before: 37,583 queries > After: 4,116 > > On top of that, an additional 4s was saved by reusing a single connection > rather than opening and closing them all the time, bringing the final number > down to 93s. (We can get away with this because we're committing any > on-cursor-initialization setup, whereas the old TestCase rolled it back.) > > Here's the code: > https://github.com/erikrose/test-utils/blob/master/test_utils/__init__.py#L121. > I'd love to generalize it a bit (to fall back to the old behavior with > non-transactional backends, for example) and offer it as a patch to Django > proper, replacing TestCase. Thoughts? > > (If you notice that copy-and-paste of loaddata sitting off to the side in > another module, don't fret; in the patch, that would turn into a refactoring > of loaddata to make the computation of the fixture-referenced tables > separately reusable.) > > This is the one I'm most interested. I did a patch a number of months ago to do the fixture parsing, but not DB insertion on a per-class basis. I didn't find that to be a big win. However, I'm going to be working on a patch to do bulk inserts (that is a single execute/executemany call for all objects to be inserted), which could be a big win for fixture loading, so I'd kind of like to do that first, to see how big a win this is after that. This is obviously more specialized, and invasive (IMO), so if we can get most of the win without it that might be good enough. > > 2. Fixture grouping > > I next observed that many test classes reused the same sets of fixtures, > often via subclassing. After the previous optimization, our tests still > loaded fixtures 114 times, even though there were only 11 distinct sets of > them. So, I thought: why not write a custom testrunner that buckets the > classes by fixture set and advises the classes that, unless they're the > first or last in a bucket, they shouldn't bother tearing down or setting up > the fixtures, respectively? This took the form of a custom nose plugin (we > use nose for all our Django stuff), and it took another quarter off the test > run: > > Before: 97s > After: 74s > > Of course, test independence is still preserved. We're just factoring out > pointlessly repeated setup. > > I don't really have plans to upstream this unless someone calls for it, but > I'll be making it available soon, likely as part of django-nose. > > No particular thoughts at the moment. > 3. Startup optimizations > > At this point, it was bothering me that, just to run a single test, I had > to wait through 15s of DB initialization (mostly auth_permissions and > django_content_type population)—stuff which was already perfectly valid from > the previous test run. So, building on some work we had already done in this > direction, I decided to skip the teardown of the test DB and, symmetrically, > the setup on future runs. If you make schema changes, just set an env var, > and it wipes and remakes the DB like usual. I could see pushing this into > django-nose as well, but it's got the hackiest implementation and can > potentially confuse users. I mention it for completeness. > > Before: startup time 15s > After: 3s (There's quite a wide variance due to I/O caching luck.) > > Code: https://github.com/erikrose/test-utils/commit/b95a1b7 > > This is another thing that I think we can get most of the win from doing the bulk inserts. Given this looks rather specialized (and if you have other custom syncdb hooks
Re: Test optimizations (2-5x as fast)
You sir, are my personal hero for the day :) We had also been looking at how we could speed up the fixture loading (we were almost ready to go so far as to make one giant fixture that just loaded at the start of the test runner). This is awesome progress On May 13, 4:57 pm, Erik Rose wrote: > tl;dr: I've written an alternative TestCase base class which makes > fixture-using tests much more I/O efficient on transactional DBs, and I'd > like to upstream it. > > Greetings, all! This is my first django-dev post, so please be gentle. :-) I > hack on support.mozilla.com, a fairly large Django site with about 1000 > tests. Those tests make heavy use of fixtures and, as a result, used to take > over 5 minutes to run. So, I spent a few days seeing if I could cut the > amount of DB I/O needed. Ultimately, I got the run down to just over 1 > minute, and almost all of those gains are translatable to any Django site > running against a transactional DB. No changes to the apps themselves are > needed. I'd love to push some of this work upstream, if there's interest (or > even lack of opposition ;-)). > > The speedups came from 3 main optimizations: > > 1. Class-level fixture setup > > Given a transaction DB, there's no reason to reload fixtures via dozens of > SQL statements before every test. I made use of setup_class() and > teardown_class() (yay, unittest2!) to change the flow for TestCase-using > tests to this: > a. Load the fixtures at the top of the class, and commit. > b. Run a test. > c. Roll back, returning to pristine fixtures. Go back to step b. > d. At class teardown, figure out which tables the fixtures loaded into, > and expressly clear out what was added. > > Before this optimization: 302s to run the suite > After: 97s. > > Before: 37,583 queries > After: 4,116 > > On top of that, an additional 4s was saved by reusing a single connection > rather than opening and closing them all the time, bringing the final number > down to 93s. (We can get away with this because we're committing any > on-cursor-initialization setup, whereas the old TestCase rolled it back.) > > Here's the > code:https://github.com/erikrose/test-utils/blob/master/test_utils/__init_ > I'd love to generalize it a bit (to fall back to the old behavior with > non-transactional backends, for example) and offer it as a patch to Django > proper, replacing TestCase. Thoughts? > > (If you notice that copy-and-paste of loaddata sitting off to the side in > another module, don't fret; in the patch, that would turn into a refactoring > of loaddata to make the computation of the fixture-referenced tables > separately reusable.) > > 2. Fixture grouping > > I next observed that many test classes reused the same sets of fixtures, > often via subclassing. After the previous optimization, our tests still > loaded fixtures 114 times, even though there were only 11 distinct sets of > them. So, I thought: why not write a custom testrunner that buckets the > classes by fixture set and advises the classes that, unless they're the first > or last in a bucket, they shouldn't bother tearing down or setting up the > fixtures, respectively? This took the form of a custom nose plugin (we use > nose for all our Django stuff), and it took another quarter off the test run: > > Before: 97s > After: 74s > > Of course, test independence is still preserved. We're just factoring out > pointlessly repeated setup. > > I don't really have plans to upstream this unless someone calls for it, but > I'll be making it available soon, likely as part of django-nose. > > 3. Startup optimizations > > At this point, it was bothering me that, just to run a single test, I had to > wait through 15s of DB initialization (mostly auth_permissions and > django_content_type population)—stuff which was already perfectly valid from > the previous test run. So, building on some work we had already done in this > direction, I decided to skip the teardown of the test DB and, symmetrically, > the setup on future runs. If you make schema changes, just set an env var, > and it wipes and remakes the DB like usual. I could see pushing this into > django-nose as well, but it's got the hackiest implementation and can > potentially confuse users. I mention it for completeness. > > Before: startup time 15s > After: 3s (There's quite a wide variance due to I/O caching luck.) > > Code:https://github.com/erikrose/test-utils/commit/b95a1b7 > > If you read this far, you get a cookie! I welcome your feedback on merging > optimization #1 into core, as well as any accusations of insanity re: #2 and > #3. FWIW, everything works great without touching any of the tests on 3 of > our Django sites, totaling over 2000 tests. > > Best regards and wishes for a happy weekend, > Erik Rose > support.mozilla.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-d
Re: Test optimizations (2-5x as fast)
Also, one thing I'm quickly noticing (I'm a bit confused why its setup_class and not setUpClass as well), but this wont work with postgres without changing the DELETE code to work like the test runner's TRUNCATE foo, bar; (due to foreign key constraints). On May 13, 9:42 pm, David Cramer wrote: > You sir, are my personal hero for the day :) > > We had also been looking at how we could speed up the fixture loading > (we were almost ready to go so far as to make one giant fixture that > just loaded at the start of the test runner). This is awesome progress > > On May 13, 4:57 pm, Erik Rose wrote: > > > > > > > > > tl;dr: I've written an alternative TestCase base class which makes > > fixture-using tests much more I/O efficient on transactional DBs, and I'd > > like to upstream it. > > > Greetings, all! This is my first django-dev post, so please be gentle. :-) > > I hack on support.mozilla.com, a fairly large Django site with about 1000 > > tests. Those tests make heavy use of fixtures and, as a result, used to > > take over 5 minutes to run. So, I spent a few days seeing if I could cut > > the amount of DB I/O needed. Ultimately, I got the run down to just over 1 > > minute, and almost all of those gains are translatable to any Django site > > running against a transactional DB. No changes to the apps themselves are > > needed. I'd love to push some of this work upstream, if there's interest > > (or even lack of opposition ;-)). > > > The speedups came from 3 main optimizations: > > > 1. Class-level fixture setup > > > Given a transaction DB, there's no reason to reload fixtures via dozens of > > SQL statements before every test. I made use of setup_class() and > > teardown_class() (yay, unittest2!) to change the flow for TestCase-using > > tests to this: > > a. Load the fixtures at the top of the class, and commit. > > b. Run a test. > > c. Roll back, returning to pristine fixtures. Go back to step b. > > d. At class teardown, figure out which tables the fixtures loaded into, > > and expressly clear out what was added. > > > Before this optimization: 302s to run the suite > > After: 97s. > > > Before: 37,583 queries > > After: 4,116 > > > On top of that, an additional 4s was saved by reusing a single connection > > rather than opening and closing them all the time, bringing the final > > number down to 93s. (We can get away with this because we're committing any > > on-cursor-initialization setup, whereas the old TestCase rolled it back.) > > > Here's the > > code:https://github.com/erikrose/test-utils/blob/master/test_utils/__init_ > > I'd love to generalize it a bit (to fall back to the old behavior with > > non-transactional backends, for example) and offer it as a patch to Django > > proper, replacing TestCase. Thoughts? > > > (If you notice that copy-and-paste of loaddata sitting off to the side in > > another module, don't fret; in the patch, that would turn into a > > refactoring of loaddata to make the computation of the fixture-referenced > > tables separately reusable.) > > > 2. Fixture grouping > > > I next observed that many test classes reused the same sets of fixtures, > > often via subclassing. After the previous optimization, our tests still > > loaded fixtures 114 times, even though there were only 11 distinct sets of > > them. So, I thought: why not write a custom testrunner that buckets the > > classes by fixture set and advises the classes that, unless they're the > > first or last in a bucket, they shouldn't bother tearing down or setting up > > the fixtures, respectively? This took the form of a custom nose plugin (we > > use nose for all our Django stuff), and it took another quarter off the > > test run: > > > Before: 97s > > After: 74s > > > Of course, test independence is still preserved. We're just factoring out > > pointlessly repeated setup. > > > I don't really have plans to upstream this unless someone calls for it, but > > I'll be making it available soon, likely as part of django-nose. > > > 3. Startup optimizations > > > At this point, it was bothering me that, just to run a single test, I had > > to wait through 15s of DB initialization (mostly auth_permissions and > > django_content_type population)—stuff which was already perfectly valid > > from the previous test run. So, building on some work we had already done > > in this direction, I decided to skip the teardown of the test DB and, > > symmetrically, the setup on future runs. If you make schema changes, just > > set an env var, and it wipes and remakes the DB like usual. I could see > > pushing this into django-nose as well, but it's got the hackiest > > implementation and can potentially confuse users. I mention it for > > completeness. > > > Before: startup time 15s > > After: 3s (There's quite a wide variance due to I/O caching luck.) > > > Code:https://github.com/erikrose/test-utils/commit/b95a1b7 > > > If you read this far, you get a cookie! I w
Re: Test optimizations (2-5x as fast)
More quick notes. You can do something like this to handle the flushing: sql_list = connection.ops.sql_flush(no_style(), tables, connection.introspection.sequence_list()) for sql in sql_list: cursor.execute(sql) Unfortunately, you're still reliant that nothing was created with signals that uses constraints. For us this is very common, and I can't imagine we're an edge case there On May 13, 9:42 pm, David Cramer wrote: > You sir, are my personal hero for the day :) > > We had also been looking at how we could speed up the fixture loading > (we were almost ready to go so far as to make one giant fixture that > just loaded at the start of the test runner). This is awesome progress > > On May 13, 4:57 pm, Erik Rose wrote: > > > > > > > > > tl;dr: I've written an alternative TestCase base class which makes > > fixture-using tests much more I/O efficient on transactional DBs, and I'd > > like to upstream it. > > > Greetings, all! This is my first django-dev post, so please be gentle. :-) > > I hack on support.mozilla.com, a fairly large Django site with about 1000 > > tests. Those tests make heavy use of fixtures and, as a result, used to > > take over 5 minutes to run. So, I spent a few days seeing if I could cut > > the amount of DB I/O needed. Ultimately, I got the run down to just over 1 > > minute, and almost all of those gains are translatable to any Django site > > running against a transactional DB. No changes to the apps themselves are > > needed. I'd love to push some of this work upstream, if there's interest > > (or even lack of opposition ;-)). > > > The speedups came from 3 main optimizations: > > > 1. Class-level fixture setup > > > Given a transaction DB, there's no reason to reload fixtures via dozens of > > SQL statements before every test. I made use of setup_class() and > > teardown_class() (yay, unittest2!) to change the flow for TestCase-using > > tests to this: > > a. Load the fixtures at the top of the class, and commit. > > b. Run a test. > > c. Roll back, returning to pristine fixtures. Go back to step b. > > d. At class teardown, figure out which tables the fixtures loaded into, > > and expressly clear out what was added. > > > Before this optimization: 302s to run the suite > > After: 97s. > > > Before: 37,583 queries > > After: 4,116 > > > On top of that, an additional 4s was saved by reusing a single connection > > rather than opening and closing them all the time, bringing the final > > number down to 93s. (We can get away with this because we're committing any > > on-cursor-initialization setup, whereas the old TestCase rolled it back.) > > > Here's the > > code:https://github.com/erikrose/test-utils/blob/master/test_utils/__init_ > > I'd love to generalize it a bit (to fall back to the old behavior with > > non-transactional backends, for example) and offer it as a patch to Django > > proper, replacing TestCase. Thoughts? > > > (If you notice that copy-and-paste of loaddata sitting off to the side in > > another module, don't fret; in the patch, that would turn into a > > refactoring of loaddata to make the computation of the fixture-referenced > > tables separately reusable.) > > > 2. Fixture grouping > > > I next observed that many test classes reused the same sets of fixtures, > > often via subclassing. After the previous optimization, our tests still > > loaded fixtures 114 times, even though there were only 11 distinct sets of > > them. So, I thought: why not write a custom testrunner that buckets the > > classes by fixture set and advises the classes that, unless they're the > > first or last in a bucket, they shouldn't bother tearing down or setting up > > the fixtures, respectively? This took the form of a custom nose plugin (we > > use nose for all our Django stuff), and it took another quarter off the > > test run: > > > Before: 97s > > After: 74s > > > Of course, test independence is still preserved. We're just factoring out > > pointlessly repeated setup. > > > I don't really have plans to upstream this unless someone calls for it, but > > I'll be making it available soon, likely as part of django-nose. > > > 3. Startup optimizations > > > At this point, it was bothering me that, just to run a single test, I had > > to wait through 15s of DB initialization (mostly auth_permissions and > > django_content_type population)—stuff which was already perfectly valid > > from the previous test run. So, building on some work we had already done > > in this direction, I decided to skip the teardown of the test DB and, > > symmetrically, the setup on future runs. If you make schema changes, just > > set an env var, and it wipes and remakes the DB like usual. I could see > > pushing this into django-nose as well, but it's got the hackiest > > implementation and can potentially confuse users. I mention it for > > completeness. > > > Before: startup ti
Re : [GSoC form rendering] Weekly check-in -1.0
Hello Gregor, just FYI, one of the guy from django-cms created django-sekizai, which is used just for that (injecting stuff in template blocks) : https://github.com/ojii/django-sekizai Mathieu -- 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.
