[Zope-dev] Re: [Checkins] SVN: Zope/trunk/ Fixed collector 2057: Testing.makequest broke getPhysicalPath()

[Paul Winkler]

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.
(snip)
> 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 :-)

-- 

Paul Winkler
http://www.slinkp.com