Hi Istvan,
though I haven't yet looked at your test code changes, this sounds
great! I've experienced exactly the same frustration, of spending a
large chunk of time tracking down an apparent bug only to find that it
was a problem with the testing framework and not pygr. So this sounds
really beneficial. A few comments below...
-- Chris
On Jan 6, 2009, at 7:11 AM, Istvan Albert wrote:
> - no more driveby-file-bombing: test data files live in the data
> directory, all temporary files are created in the temp subdirectory
> (that will be created automatically), the only file that I was unable
> to move to temp is the downloaded file.
You can specify the directory where the file should be downloaded to
via the environment variable PYGRDATADOWNLOAD... if you incorporate
that into the tests, it will be the first time the test suite
specifically checks this feature!
>
> - no more access errors on windows (due to removing files without them
> being closed, windows would complain)
If you have a list of places where files are not being closed (and
should be), please send that to me so I can fix them.
>
> - removed dependency on nose, tests are based on unittest. I found the
> old protest.py to be a little convoluted, since I don't know that the
> reason for running every testmodule in a new python interpreter was I
> just bypassed that, the advantage is that this makes it a mere 10 or
> so lines of actual code.
I used nose because Titus recommended it. He can probably list its
advantages / disadvantages better than I can. But I ran into some
wierd nose behavior ("bugs" due to the test framework, just as you
encountered), and threw together protest.py mainly because I wanted to
test persistence (pygr.Data) in a separate process for each test
(discussed further below).
But the test code still used nosebase classes to handle things like
automatically skipping tests whose setup() fails in specified ways
(e.g. can't import mysqldb, or can't access the Internet to do the
download test). How are you handling this test-skipping contingency?
Have you tested your changes under various conditions like a machine
disconnected from the network or lacking the mysqldb module, to ensure
that the test skipping still works seamlessly?
How are you handling the XMLRPC server test? This test runs the
xmlrpc server as a separate process. The parent process performs a
series of client tests (requesting data from the server), then tells
the server to shutdown using an XMLRPC call.
> - pygr.Data really needs a standalone and isolated namespace, I have
> spent a few days trying to make one but finally gave up, there are
> lots redirections there, with global names etc that makes
> understanding the code difficult. Currently, I am using the path of
> least resistance, I simply overwrite the PYGRDATAPATH environment
> variable to force it to use a different path.
Let's discuss this further. As a number of us have discussed in
several threads here (and some offline conversations), I've been
planning to revamp the top-level access mechanism for pygr.Data. The
question is: should we make some simple changes right away (0.8
release), or should this wait for a major revision / expansion of
pygr.Data (currently written into the "roadmap" as release 1.0)? If
you want, I can send you links to the various discussion threads or
try to summarize my current thinking on the top-level namespace access
mechanism...
The current mechanism (accessing names directly from the top-level of
module namespace) relates to some of the annoyances you mentioned.
For example, because there is no __getattr__() mechanism for modules,
under the current mechanism all top-level names must be inserted into
the module namespace during import. That means pygr.Data has to query
its resource databases for top-level names, and add them to the module
namespace, *during import*. Because of this behavior, I felt that
pygr.Data tests should each be run in a separate process, to guarantee
that tests truly start from a "clean slate", as there is no absolutely
clean way to "un-import" a module. I dislike this behavior and have
been discussing several alternatives; the main question right now is
simply the trade-off of HOW MUCH to change vs. WHEN.
>
>
> - I think some of the tests would be better in a doctest format. For
> example the pygrdata_test that for now is only partially ported should
> be intermingled with a narrative that would also explain what the
> lines of code actually do. This could then be rendered into
> documentation thus serving a dual purpose.
Titus has recommended this too. My only caveat is that quite a number
of the tests are dull technical verifications of expected behavior.
Presumably you would only make doctests out of tests that provide an
example of an application that a user might actually want to do in
real-life...
>
>
> One of the reasons I started this is to understand better what every
> component does. In the end I had some fun with it and I am willing to
> spend more time with it, provided this is something that is positively
> received.
This seems like a really useful direction! Thank you for moving this
forward.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pygr-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/pygr-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
