-----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@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-----