overriding __getitem__ for a subclass of dict

[Steve Howell]

On Nov 17, 7:11 am, Scott David Daniels <Scott.Dani... at Acm.Org> wrote:
> Steve Howell wrote:
>
> ...
>
> > Eventually, I realized that it was easier to just monkeypatch Django
> > while I was in test mode to get a more direct hook into the behavior I
> > was trying to monitor, and then I didn't need to bother with
> > overriding __getitem__ or creating complicated wrapper objects....
>
> Since nobody else has mentioned it, I'd point you at Mock objects:
>      http://python-mock.sourceforge.net/
> for another way to skin the cat that it sounds like has been
> biting you.  They are surprisingly useful for exploratory
> and regression testing.
>

Thanks, Scott.  We do indeed use mocks in our development, and they
are useful.  In a way I am trying to emulate some of what mock objects
do, but in more on an integration testing mode.  For testing the
rendering of whole templates, it sometimes becomes convenient for at
least some of the objects that your code depends on to maintain their
implementation under the hood, but you also want to see where they're
going, which is why I want to be able to hook into the dictionary
lookup mechanism.

Even outside of pure unit testing, mock objects have been pretty
versatile in terms of giving us the lay of the land, even when we
start getting down into the Django template stack.  It is mostly when
you start interacting with the ORM that you want to start using real
objects.  On the one hand you want to isolate yourselves from the ORM
behavior to validate the rest of your code, but sometimes it is
difficult to emulate the exact semantics of the ORM, or maybe you are
trying to get a handle on where the ORM is hitting the database,
etc.

The so-called "real world" situations are when you start wanting a
messy hybrid of mock objects, merely-spied-on objects, real objects,
etc.