On Mon, Aug 17, 2009 at 5:54 AM, Brandon Craig Rhodes<[email protected]> wrote: > > Lucie Lejard <[email protected]> writes: > >> this might help: >> >> http://plone.org/products/getpaid/documentation/how-to/how-do-i-run-tests-for-getpaid/ > > Thank you, Lucie! That document helped me get started, and in the > future it might possibly make a nice addition to the README of the > GetPaid buildout. > > I still can't run the tests for getpaid.googlecheckout, however. > > 1. The module, by default, is not in the path of "bin/test" so when I > try running: > > $ bin/test -s getpaid.googlecheckout > > then I get the error: > > ImportError: No module named googlecheckout > > Sure enough, an inspection of the "bin/test" binary that buildout > has created shows that "googlecheckout" is nowhere in the path that > gets built. Looking over the several instances of the string > "googlecheckout" that do appear in the "buildout.cfg" of > "getpaid.buildout" (all are commented out to begin with),
getpaid.googlecheckout (along with other async processors) makes use of zcml overrides to patch PloneGetPaid. You need to opt in to which ever async processor you want to use. Essentially they are mutually exclusive from each other. And they change the behaviour of PloneGetPaid. > none of > them seem positioned to affect the binaries that "bin/test" can > see. So, I edited the "[test]" section and under the "eggs =" > parameter added "getpaid.googlecheckout" and re-ran buildout. The > result was successful: the "googlecheckout" module became available > for testing. Looks like the test part in the buildout is configured to just work for the more isolated packages. To run the tests for getpaid.googlecheckout use the second method detailed in that document: bin/instance test -s getpaid.googlecheckout > 2. Now another error appeared. Running "bin/test" again, like this: > > $ bin/test -s getpaid.googlecheckout > > returned with another import error: > > File > "/home/brandon/getpaid.buildout/src/getpaid.core/src/getpaid/core/fields.py", > line 26, in ? > from Products.validation import validation > ImportError: No module named validation > > that again prevented any tests from running. I am not sure exactly > what "Products.validation" is, but, looking all over the getpaid > buildout, I certainly do not see it anywhere. Both of the > following commands do find some files: > > $ cd ~/getpaid.buildout > $ find -name 'Products' > $ find -name 'validation' > > but none of the resulting files has a "validation" module *inside* > a package called "Products". So, not being sure how to proceed, I > manually added "Products.validation" as a dependency in the > "setup.py" file of "getpaid.core", since that seems to be the > module that imports it. After re-running buildout, the import > error went away. > > 3. Now I am faced with a third error deep. Running: > > $ bin/test -s getpaid.googlecheckout > > returns: > > File > "/home/brandon/getpaid.buildout/parts/zope2/lib/python/App/ImageFile.py", > line 46, in __init__ > data = open(path, 'rb').read() > IOError: [Errno 2] No such file or directory: > '/home/brandon/getpaid.buildout/src/Products.PloneGetPaid/AccessControl/www/User_icon.gif' > > At this point I am reaching a bit beyond my expertise; I am not > sure why the "User_icon.gif" file is being looked for beneath the > "Products.PloneGetPaid" folder, when it's clearly somewhere else: > > $ find -name 'User_icon.gif' > ./parts/zope2/lib/python/AccessControl/www/User_icon.gif > > Hence, my email to this list: I suspect that, in trying to get the > module's tests running inside of the master buildout, and > especially in they way that I'm trying to make > "Products.validation" available, I'm going outside of what the > whole Plone and getpaid buildout system intends. See how "bin/instance test" treats you. > Is it wrong to want the googlecheckout tests, and the tests of all of > the other getpaid modules in "src/", to run all at once? Unfortunately yes. :-( The problem is the necessarily use of overrides. For example getpaid.googlecheckout changes the behaviour of PloneGetPaid and so you can expect that it most likely breaks the tests of PloneGetPaid itself. > Should I > tackle the modules one at a time using their own "buildout.cfg" files > instead of wanting to test them all from a single "getpaid" buildout? Only the modules that make use of overrides require such an isolation. It's not ideal having to mess around with overrides. There is an issue that is use for at least auditing the extent of the problem: http://code.google.com/p/getpaid/issues/detail?id=167 There is an effort underway which should improve the situation. See the new getpaid.paymentprocessors package. Though I think that has a slightly different focus - it's interested in presenting multiple payment options to the shopper. Which necessary means that any one payment processor needs to be able to play along nicely next to other payment processors to support that. A side effect of that work may well be that several payment processors could be installed (and tested) at the same time even when a plone site is not offering multiple payment processors to the shopper. But I don't think that is a use case yet under consideration by getpaid.paymentprocessors. -- Michael Dunstan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "getpaid-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en -~----------~----~----~----~------~----~------~--~---
