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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Winkler wrote:
> On Thu, Apr 06, 2006 at 11:17:20AM +0200, Stefan H. Holek wrote:
> 
>>For the record: I am still opposed to this change. It basically  
>>endows the request (as in self.REQUEST) with a getPhysicalPath  
>>method, and I have no idea what kind of side-effects this may have.
> 
> 
> That's because there aren't any ;-)
> 
> The only way you can ever hit REQUEST.getPhysicalPath is if
> you specifically ask for it, which is obviously stupid; or if
> the object you're wrapping doesn't terminate getPhysicalPath().
>  
> 
>>AFAICS your test suite is the only suite around that wants to request- 
>>wrap non-root objects. 
> 
> 
> I'd reprhase that as "... wants to request-wrap non-Zope2.app()
> objects."
> 
> FWIW, I didn't write it, and at the time those tests were added,
> I believe they worked.  This was using zope 2.8.something.
> 
> I know who originally added those tests,

That would be me.  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 was hired several months later and discovered some apparent bit-rot in
> our test suite, i.e. a number of failures and errors, and one of the
> principal points of failure was the issue we're discussing.
> I'm not sure, but I'm guessing that the calls to getPhysicalPath() in
> our app were added later, and whoever did that must've punted on
> figuring out the resulting test issues.

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).

> 
>>There's nothing wrong with using your own  
>>makerequest for your own test suite, if this is what you want. But I  
>>don't think your use-case warrants changing Zope.
> 
> 
> Noted, and that's a reasonable position. Does nobody else care?

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.

> Using an Item or Folder as your root object for tests works fine except for
> this one issue, so why not allow that?
> My feeling is that setting up an app is unnecessary work when you
> don't need one; for one thing, your test module needs to call
> Zope2.startup() first; for another, afaict creating a Zope2.app is 
> a couple orders of magnitude slower than creating a SimpleItem.
> 
> So maybe more people *should* use makerequest(NotAnApp) ;-)

+1.


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFENY+6+gerLs4ltQ4RAiB7AJ9s/Ntu6pkWN8nyiQ6ifNfCj7DgPwCgzg0g
SwE3IdhmcFdEnDL5kIpIiYU=
=26iW
-----END PGP SIGNATURE-----