> Also, do you know how we could get
> individual unit tests to run 'out of the box', i.e. you don't need to
> manually set any paths?
Is this inside relax or is stand alone on the command line? If it is the
latter that was what I was looking at this morning. You just make
unit_test_runner.py executable and give it the name of directory with
some unit tests in it or give it the name of a python source file with a
single unit test in it... However, as you can see i am having problems
with the __builtins__ namespace
https://mail.gna.org/public/relax-devel/2007-02/msg00003.html
The original idea was to be able to run individual tests on the
command line wasn't it? For debugging this would help significantly
and save our sanity, especially if the test suite were to become quite
large. As for your other post, I just responded to it. It should
appear at https://mail.gna.org/public/relax-devel/2007-02 sometime
soon (that was just a shameless plug, just as http://nmr-relax.com is,
to help with search engine indexing ;).
The other thing to say here is that the use of global variables in a
threaded version of relax could be annoying vearing on to the dangerous
so we do need to head towards some form of thread local storage fopr
'pseudo globals'...
I don't see this as an issue. For the RelaxError and RelaxWarning
objects there is no issue. For the '__builtin__.Debug',
'__builtin__.Pedantic', and '__builtin__.warn' flags these can default
to off in the threads. If need be we can explicitly set the flags in
the threads via the parent thread.
Maybe we should move all the __builtin__ addition defaults into the
file 'builtin.py' in the base relax directory (1.3 line only). Then
the threads, including the parent run from the command line, can
import this module and be happy. Each unit test module could also
import this module (and we could maybe check this behaviour via other
unit tests). What do you think?
Bye,
Edward
Re: r3033 - /1.3/test_suite/unit_tests/unit_test_runner.py