On Thu, Apr 06, 2006 at 06:01:30PM -0400, Tres Seaver wrote:
> Paul Winkler wrote:
> > I know who originally added those tests,
> That would be me.
I was hoping you'd pop in :-)
> I don't see anything wrong with using a non-Zope2-app
> object for unit testing: in fact, I think it is *superior* practice.
> Most tests don't need to have the whole shooting match of the Zope
> startup dance done, and in fact will be better unit tests if they are
> tested *outside* of that environment.
> I think you will see lots of usage of the pattern in CMF and related
> products: the RequestTest and SecurityRequestTest base classes from
> CMFCore are used *everywhere*. The only caveat is that, if your tests
> *needs* to call 'getPhysicalPath' and get a "realistic" value, you need
> to ensure that the object used as the root does the Right Thing (TM).
Interesting. I'd forgotten that RequestTest et al. used this stuff;
I had another look and what gets wrapped in makerequest there is
whatever you get when you do Zope2.DB.open().root()['Application'].
Is that not a Zope2.app?
tangent: I really wish I'd looked at tests/base/testcase.py sooner,
because I wasted time rewriting our LogInterceptor to work with the
logging package - I didn't realize that a) it was a copy-paste from
CMFCore, and b) the logging update was already done for CMF 2 if not
sooner. Doh! Copy-paste is evil. Oh well, I learned some things about
the logging package.
> I don't beleive that "must be a Zope2.app()" is a real part of the
> contract of 'makerequest': "must be able to emulate one well enough for
> the rest of the test to succeed" is.
That's a good thing to note in the docstrings. I'll go do that. Also
I'll remove the getPhysicalPath() hackery. I don't really agree with
Stefan that it's dangerous, but certainly it smells bad :-)
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -