how to run tests?
Brandon Craig Rhodes
running its tests. I cannot find anything about running tests here:
http://code.google.com/p/getpaid/wiki/DevGettingStarted
So I played around a bit with the "getpaid.buildout" and discovered
that:
$ bin/instance test getpaid.core
indeed runs a smattering of tests (23 was the count) and succeeds. But
running the more conventional command:
$ bin/test
results in all sorts of problems with simplejson lacking 'test_suite'
objects in its modules, and with a problem import when trying to run
"getpaid.core.tests.test_order":
from Products.validation import validation
ImportError: No module named validation
My question is: how can I run the tests of all of the various
"getpaid.*" pieces, all at once, using "getpaid.buildout"? I want to
see that the tests succeed; I want to then go read the tests, since
tests tend to be pretty up-to-date documentation on how something works;
and I want to measure the code-coverage achieved by the current suite.
Thanks for any pointers!
--
Brandon Craig Rhodes bra...@rhodesmill.org http://rhodesmill.org/brandon
Lucie Lejard
http://plone.org/products/getpaid/documentation/how-to/how-do-i-run-tests-for-getpaid/
Lucie
--
six feet up, inc. | "Nowhere to go but open source"
Direct Line +1 (317) 861-5948 x605
http://www.sixfeetup.com | Zope/Plone Custom Development + Hosting
Brandon Craig Rhodes
> 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), 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.
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.
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? 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?
Let me know. Thanks!
Michael Dunstan
Rhodes<bra...@rhodesmill.org> wrote:
>
> Lucie Lejard <lucie...@gmail.com> 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
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
Christopher Johnson
-c
Cofounder and CEO
ifPeople - Innovation for People
www.ifpeople.net
t: 678-608-3408
130 Boulevard NE, #6
Atlanta, GA 30312
Brandon Craig Rhodes
> Brandon - hopefully that clarifies both the situation with what you
> are trying to do as well as the problem you are trying to address
> (over-dependence on overrides for payment processors) and recent work
> to change the situation (multiple payment processors) :D
I'm not sure the multiple-payment-processors work helps things any with
external payment processors, but I'll look for the branch that he's
talking about to see. But, yes, Michael is talking about the exact same
issue with GetPaid that I'm setting out to address: it's just turning up
here in a different situation (testing) that the situation that's really
the main concern (running a site in production). Essentially, while I
knew that a site could only have one ZCML setup, I had somehow imagined
that the test suite might have the power to run the normal tests, see
them succeed, and then activate the Google Checkout ZCML just for its
own tests.
Apparently not. :-)
Michael Dunstan
Rhodes<bra...@rhodesmill.org> wrote:
>
> Christopher Johnson <cjj.if...@gmail.com> writes:
>
>> Brandon - hopefully that clarifies both the situation with what you
>> are trying to do as well as the problem you are trying to address
>> (over-dependence on overrides for payment processors) and recent work
>> to change the situation (multiple payment processors) :D
>
> I'm not sure the multiple-payment-processors work helps things any with
> external payment processors, but I'll look for the branch that he's
> talking about to see.
There has been some work to support external (async) processors at
least at the API level.
I agree that multiple-payment-processors focuses on a different use case.
> But, yes, Michael is talking about the exact same
> issue with GetPaid that I'm setting out to address:
Yay - that sound great.
> it's just turning up
> here in a different situation (testing) that the situation that's really
> the main concern (running a site in production). Essentially, while I
> knew that a site could only have one ZCML setup, I had somehow imagined
> that the test suite might have the power to run the normal tests, see
> them succeed, and then activate the Google Checkout ZCML just for its
> own tests.
>
> Apparently not. :-)
Correct. I don't think the current wiring of the zcml overrides works
in a way that lets you run all the tests for all the processors.
I think that is a very worthy goal - to be able to run all the tests
for all the processors. The bug you found in the googlecheckout
processor (in the other thread) demonstrates the need for that.
It might be that a rearrangement of the zcml overrides wiring during
the tests could be pulled off to achieve that goal.
<davisagli> (I think that is who it was) on #getpaid suggested a
simple solution to the problem. Use browser layers. Get each payment
processor to create their own browser layer. And get GetPaid to swap
in the correct browser layer for the currently configured payment
processor. A payment processor can then just use the layer attribute
in ZCML to do preform whatever customisations it requires.
While that very neatly avoids the problem with overrides it does not
really provide an API for new payment processors to code against. But
that's moving onto a separate problem. The browser layer trick would
be useful to have anyway and may well provide a pathway to something
more like an API.
Though I'm not sure how that would fit in with what is happening with
the multiple-payment-processors work.
--
Michael Dunstan