On Nov 17, 7:11 am, Scott David Daniels <scott.dani...@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. -- http://mail.python.org/mailman/listinfo/python-list
