Re: Resetting settings under test
On Tue, May 17, 2011 at 6:42 PM, Jeremy Dunck wrote: > On Tue, May 17, 2011 at 11:01 AM, Jannis Leidel wrote: >>> I was looking more for transaction rollback semantics -- rather than >>> overriding (and then restoring) specific settings, I was hoping for >>> settings to be set back just as they were before the test. >> >> Yah, but the good news is that the context manager/decorator hybrid >> actually resets the settings completely (by temporarily wrapping it in a >> UserSettingsHolder) and not only the overridden settings. That's because >> the settings provided to the context manager/decorator is applied to the >> wrapper not to the actual settings instance. >> >> In other words unless I misunderstand your use case it should just >> revert to the setting instance that existed before, effectively reverting >> your middleware's changes to the setting. > > Ah, sorry, I didn't read the patch code closely enough. So yes, this > addresses my need, and on second thought, I think the mutating > middleware might do better to follow a similar pattern -- use > UserSettingsHolder and swap the existing back in upon process_response > or response_completed. Yup, this is indeed also a use case we have in some tests: enabling the settings override in setUp and disabling it in tearDown. [1] I'm not yet sure whether this is an API that deserves to be made public, but it would certainly be similar to using UserSettingsHolder manually. 1: https://github.com/jezdez/django/blob/26077dbf28c087fcdf1d/tests/regressiontests/mail/tests.py#L288-297 -- 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 Tue, May 17, 2011 at 11:01 AM, Jannis Leidel wrote: >> I was looking more for transaction rollback semantics -- rather than >> overriding (and then restoring) specific settings, I was hoping for >> settings to be set back just as they were before the test. > > Yah, but the good news is that the context manager/decorator hybrid > actually resets the settings completely (by temporarily wrapping it in a > UserSettingsHolder) and not only the overridden settings. That's because > the settings provided to the context manager/decorator is applied to the > wrapper not to the actual settings instance. > > In other words unless I misunderstand your use case it should just > revert to the setting instance that existed before, effectively reverting > your middleware's changes to the setting. Ah, sorry, I didn't read the patch code closely enough. So yes, this addresses my need, and on second thought, I think the mutating middleware might do better to follow a similar pattern -- use UserSettingsHolder and swap the existing back in upon process_response or response_completed. -- 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 17.05.2011, at 17:41, Jeremy Dunck wrote: > On Fri, May 13, 2011 at 10:10 AM, Jannis Leidel wrote: > ... >> I've added something related the other day in changeset 16165. >> > > Following up here, Jannis added a patch to a sort-of related ticket: > http://code.djangoproject.com/ticket/15561 > > This refactors the context manager into also supporting use as a decorator. > > For my use case, middleware is changing the settings, so, for example, > client.get might mutate settings. > > I was looking more for transaction rollback semantics -- rather than > overriding (and then restoring) specific settings, I was hoping for > settings to be set back just as they were before the test. Yah, but the good news is that the context manager/decorator hybrid actually resets the settings completely (by temporarily wrapping it in a UserSettingsHolder) and not only the overridden settings. That's because the settings provided to the context manager/decorator is applied to the wrapper not to the actual settings instance. In other words unless I misunderstand your use case it should just revert to the setting instance that existed before, effectively reverting your middleware's changes to the setting. 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: Resetting settings under test
On Fri, May 13, 2011 at 10:10 AM, Jannis Leidel wrote: ... > I've added something related the other day in changeset 16165. > Following up here, Jannis added a patch to a sort-of related ticket: http://code.djangoproject.com/ticket/15561 This refactors the context manager into also supporting use as a decorator. For my use case, middleware is changing the settings, so, for example, client.get might mutate settings. I was looking more for transaction rollback semantics -- rather than overriding (and then restoring) specific settings, I was hoping for settings to be set back just as they were before the test. Even so, I think maybe my use case isn't normal enough to go upstream -- and this patch shows pretty well how the general approach could be applied to my need. -- 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: 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.
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.
