[Tutor] unit testing

[Tom Plunket]

Magnus Lyckå wrote:

> At 11:05 2003-05-31 -0700, Tom Plunket wrote:
> >Sure- is there a way that I can call __import__ to look like
> >"from x import *" though?
> 
> The simplest solution I can think of is to do
> 
> for filename in glob.glob('test_*.py):
>      exec "from %s import *" % filename[:-3]
> 
> As I said, I advise against this.

Heh thanks for the tip, forgot about the fact that I could
execute arbitrary code from within my code.  :)

So that does exactly what I want, but reading the rest of what
you've written...

> Make sure that you have a big screen buffer in your cmd.exe so
> that you can scroll back if needed...

...or have another "watcher" python app that collects the results
and spits out a summary.  :)

> >That's a good point, although I do try to make sure there are no
> >dependencies anyway by limiting my use of global variables to
> >none and trying to always create new class instances.  :)
> 
> But this means that you might have problems with functions
> defined in a test module. A quick check reveals that I have
> a global function called 'init' in four of my test suites.

Oh right, I forgot about this.  Ok- that's what will make me
worrying about this, but aren't symbols preceded by an underscore
not linked into the global namespace on import?

> >C:\Documents and Settings\tom\My Documents>type test.py
> >import test.regrtest
> 
> test.py is importing itself! :) Rename it to something else.

Oh yeah.  Ugh.  Guess I have to start remembering the Python
keywords and modules.  :)

> I guess the tutorial should have something about this in large
> flaming letters where it discusses imports.

Yeah, the C++ standard library is nice like that- the standard
headers don't have .h, so I can have string.h and not screw
anything up.  ;)  Not that I'd do anything so foolish, but still.
:)

> >Hmm- there's something interesting.  Maybe I could hack unittest
> >so that it takes a list of modules to run.  ...or maybe that's
> >what that 'argv' parameter is for.  Hmm, maybe I can do it just
> >by passing my 'tests' list in as argv.
> 
> Please tell us what you found. Separate namespaces are probably
> enough protection, even if separate processes feel *very* safe...

Well, unittest.main can optionally take a module name, so it
shouldn't be too tough to make it take a list of modules.  Who do
I talk to about permission to do this and fold it back in to the
main Python codebase?

> As you see above, my total testing time is a lot longer than
> the sum of times for each test. I'm sure module loading takes
> some time, but maybe a better approach could save me ten seconds
> or so...

Yeah- I wonder if you might get some speed by searching for all
of your test files and importing them manually all at once.  Or
is that another thing you want to avoid, having everything loaded
up?  I suppose it would make sense to flush everything between
test runs, but taken to the extreme we might even prefer that the
entire interpreter shut down and restarted between each test...

> >Yes indeed- I actually had similar frustrations when moving
> >between C++ compilers, even.  The way to do things optimally
> >often depended entirely on the compiler.  :(
> 
> You mean like when you build something with Visual C++ and get
> no warnings, and in Unix you get hundreds, and realize that you
> have done things that are obviously not correct C++, but the
> "forgiving" Visual C++ compiler guessed what you meant, and didn't
> even bother to tell you that you were wrong.

Heh actually- things that work great in VC and kill the machine
in CodeWarrior, or code that works great in GCC but doesn't even
build in CW.  I hope I never have to use CW again, let me just
say...

> It's just the same as with HTML code for MS IE and other browsers.

Oh you're telling me- I've all but purged IE from my brain, got
really hooked on the way Opera worked, and it's irritating as
hell when I've got to open IE for a specific page that Opera
fails to work with...  :(


-tom!