On Nov 4, 4:26 pm, Alex Gaynor <[email protected]> wrote: > 2010/11/4 Łukasz Rekucki <[email protected]>: > > > > > > > Funny, I had exactly the same problem today at work while refactoring > > my application's tests suite :). > > > Currently, I'm using a pair of save/restore functions: save() monkey > > patches the settings module and returns a dictionary of old values, > > restore() puts back the old values based on the dictionary. I usually > > put this in setUp/tearDown so I don't have to repeat in every test. I > > was about to propose that > > Django's TestCase should do something similar by default. > > > Both the decorator and context processor are very useful, but having > > something to set values for the whole test case instead of a single > > test or a block of code would be great too. I was thinking about > > something in line of: > > > class EmailTestCase(TestCase): > > settings = dict(DEFAULT_FROM_EMAIL="[email protected]") > > > On 4 November 2010 21:11, David Cramer <[email protected]> wrote: > >> With a decorator approach here's what I whipped up: > > >> (This is dry code) > > >> def with_settings(**overrides): > >> """Allows you to define settings that are required for this > >> function to work""" > >> NotDefined = object() > >> def wrapped(func): > >> �...@wraps(func) > >> def _with_settings(*args, **kwargs): > >> _orig = {} > >> for k, v in overrides.iteritems(): > >> _orig[k] = getattr(settings, k, NotDefined) > > >> try: > >> func(*args, **kwargs) > >> finally: > >> for k, v in _orig.iteritems(): > >> if v is NotDefined: > >> delattr(settings, k) > >> else: > >> setattr(settings, k, v) > >> return _with_settings > >> return wrapped > > >> I'm not familiar with the context managers, but I imagine those would > >> solve things like adjusting CONTEXT_PROCESSORS. > > >> On Thu, Nov 4, 2010 at 1:06 PM, Dan Fairs <[email protected]> wrote: > > >>>> Let me start with an example test: > > >>>> def test_with_awesome_setting(self): > >>>> _orig = getattr(settings, 'AWESOME', None) > >>>> settings.AWESOME = True > > >>>> # do my test > >>>> ... > > >>>> settings.AWESOME = _orig > > >>> Pedant: there's a small bug above which has bitten me before doing a > >>> similar thing - settings.AWESOME ends up set to None after the test has > >>> run if it didn't exist before. > > >>>> Anyways, I'd love to hear how others have dealt with this and any > >>>> other possible solutions. > > >>> I've used Michael Foord's Mock library to patch a setting for the > >>> duration of a test case. Chris Withers' testfixtures library also has > >>> some sugar to provide a context manager approach, though I haven't used > >>> that in a little while. > > >>> Cheers, > >>> Dan > > >>> -- > >>> Dan Fairs | [email protected] |www.fezconsulting.com > > >>> -- > >>> You received this message because you are subscribed to the Google Groups > >>> "Django developers" group. > >>> To post to this group, send email to [email protected]. > >>> To unsubscribe from this group, send email to > >>> [email protected]. > >>> For more options, visit this group > >>> athttp://groups.google.com/group/django-developers?hl=en. > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Django developers" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> For more options, visit this group > >> athttp://groups.google.com/group/django-developers?hl=en. > > > -- > > Łukasz Rekucki > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/django-developers?hl=en. > > Well, there's no reason the decorator couldn't be used as a class > decorator (on 2.6 and above). I'll admit that the settings attribute > on TestCase is more consistant with how we've handled other things > (urls, fixtures), however, for whatever reason I'm not a fan, as it > forces you to split up tests that should logically be grouped on a > single class. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your > right to say it." -- Voltaire > "The people's good is the highest law." -- Cicero > "Code can always be simpler than you think, but never as simple as you > want" -- Me
What if it worked like self.client. So self.settings would be the current settings with ability to overwrite values in your tests then self.settings could be reset on each test run. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
