how to run tests?

[Brandon Craig Rhodes]

I am going to help with some work on GetPaid, and wanted to start by
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   brandon@...   http://rhodesmill.org/brandon

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Lucie Lejard-2]

this might help:

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 [phone] x605
http://www.sixfeetup.com  |  Zope/Plone Custom Development + Hosting



On Wed, Aug 12, 2009 at 1:50 PM, Brandon Craig
Rhodes<brandon@...> wrote:

>
> I am going to help with some work on GetPaid, and wanted to start by
> 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   brandon@...   http://rhodesmill.org/brandon
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Brandon Craig Rhodes]

Lucie Lejard <lucielejard@...> 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), 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!

--
Brandon Craig Rhodes   brandon@...   http://rhodesmill.org/brandon

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Michael Dunstan]

On Mon, Aug 17, 2009 at 5:54 AM, Brandon Craig
Rhodes<brandon@...> wrote:

>
> Lucie Lejard <lucielejard@...> 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 getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Christopher Johnson-7]

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

-c

On Sun, Aug 16, 2009 at 7:03 PM, Michael Dunstan <michael.dunstan@...> wrote:

On Mon, Aug 17, 2009 at 5:54 AM, Brandon Craig
Rhodes<brandon@...> wrote:
>
> Lucie Lejard <lucielejard@...> 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

--
Cofounder and CEO
ifPeople - Innovation for People
www.ifpeople.net
t: 678-608-3408
130 Boulevard NE, #6
Atlanta, GA 30312

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Brandon Craig Rhodes]

Christopher Johnson <cjj.ifpeople@...> 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.  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. :-)

--
Brandon Craig Rhodes   brandon@...   http://rhodesmill.org/brandon

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Michael Dunstan]

On Tue, Aug 18, 2009 at 3:21 PM, Brandon Craig
Rhodes<brandon@...> wrote:

>
> Christopher Johnson <cjj.ifpeople@...> 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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en
-~----------~----~----~----~------~----~------~--~---