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