From: Terry Reedy on 23 Apr 2010 15:05
On 4/23/2010 8:03 AM, Cameron Simpson wrote:
> On 23Apr2010 13:25, Peter Otten<__peter__(a)web.de> wrote:
> | Move the unit tests into a separate script and have that import the module
> | cs.nodedb.node.
> Hmm. I have been very attracted by the idea of having the unittest in
> the module itself, and run if I "run" the module alone (instead of
> importing it).
I do this too. edit, run (F5 in IDLE), (click back to edit window) edit,
run, ... several times in an hour. Very nice.
But... I have simpler modules (function, not class definitions) and no
circular imports. So I was thinking the same thing Peter said for your case.
> Conversely, I've also got a few modules that are standalone programs
> and running _then_ runs the app, not a bunch of tests.
> Having the tests elsewhere would solve the problem as you say; an import
> of the module is what "real" code will be doing and, as my misadventure
> above demonstrates, that's a different thing as far as namespaces go.
> | In general, avoid importing a module and at the same time using it as the
> | main script.
> Fsir enough - that's a succinct description of what I did wrong.
Several people have posted problems that amount to this. An 'exciting
gotcha' indeed ;-).
Terry Jan Reedy
From: Gabriel Genellina on 23 Apr 2010 15:35
En Fri, 23 Apr 2010 03:15:16 -0300, Cameron Simpson <cs(a)zip.com.au>
> On 23Apr2010 15:37, I wrote:
> | Experienced users will see at once what's happened: I've made a Node
> | myself in the test using the local class, and the Node class is thus
> | __main__.Node. However, my sql Backend class has independently imported
> | the "Node" and "Backend" classes from "cs.nodedb.node". So when _it_
> | calls serialise(), "Node" is "cs.nodedb.node.Node".
> A walk around the block and I'm thinking the olny sane way to do this is
> to use relative imports, to always get the sqla.py module from the same
> place as the node.py where the test lives, and likewise in sqla.py
> to relatively import node.py to get its matching file.
Another way is to split the test code and move it into its own module.
This way, the testing code will import the node module the same way the
real application would do.