On 3/6/07, Gary S. Thompson <garyt@xxxxxxxxxxxxxxx> wrote:
Edward d'Auvergne wrote:
> The function arguments are definitely clearly described.
oh good!
> Do you think
> that the arguments of the command line usage of 'unit_test_runner.py'
> should be sent in as the argument 'test_module' or the argument
> 'root_path'? Is 'test_module' supposed to be a file name or module
> name (eg. 'data/test_diff_tensor.py' vs 'data.test_diff_tensor')?
oh bad! obviously not quite well enough defined... a module name
My confusion lies in the fact that I was expecting that I could supply
a file name (i.e. having access to the all important shell tab
completion abilities) but the documentation says module names - which
don't have the tab completion ability. For the class this doesn't
matter but for the stand alone operation of 'unit_test_runner.py',
typing the module names in full rather than tab completing to the file
name could be a source of severe wrist pain :(
> For the argument 'rootSystemDirectory', could this not be changed to a
> single string? The second array element, the relative path, could
> easily be determined by a function which converts all directories in
> the first element to '..' (well actually 'os.pardir' to be
> cross-platform compatible). Oh, I just noticed but the directory
> separators should be made OS independent and portable by using the
> 'sep' variable from the 'os' module. It may be possible to also write
> a function which determines these directories automatically, removing
> the need for the argument (eg. walking up directories from os.getcwd()
> until an executable file 'relax' is found). Would it be possible to
> determine the values of the 'root_unit_test_directory' argument
> automatically as well?
There are a few things here
1. yes I should be using os.pardir() and I have bee trying to use
os.sep, if it is missing its an oversight
These things will sort themselves out when people run the relax tests
on non-Posix systems. After making relax cross platform compatible I
now try to remember to never use directory paths as plain strings.
2. both the unit test funtion and the system directoy function pass into
a general directory searcher
so the second argument is needed
I suppose the generality could be useful for the future integration of
the system/function tests into the framework. If this is the idea (?)
removal of 'unit' from the documentation, variables, methods,
functions, and classes might be an idea.
3. I could look for an executable relax file but I feel makes me more
dystem dependant than looking for a directory structure
A hard coded directory structure pattern, throwing a RelaxError if
there is no match to handle directory structure changes, could be the
most flexible solution simplifying the work required by the user of
the Run_unit_tests class. It's not essential though but would make
the use of the class instance easier to understand (without looking at
the code).
> One last thing is do we need the 'test_pattern' argument? I think we
> should enforce that unit test files must always start with 'test_' and
> end in '.py'. Can you see exceptions to this rule requiring the
> argument?
I don't in general see any exceptions to this rule , but I designed the
setup to be general again. I guess the search string could be come an
inrenal constant
If it were a non-private constant of the module, then the user of the
module could change it if desired. I'm just thinking of ways of
simplifying the class usage, hence simplifying its description. These
ideas have no operational effects so don't worry about it if you
prefer the flexibility.
> Also do you think that we should have a single unit test
> file per relax module? I can see value in not enforcing this rule.
> For example the 'specific_fns.model_free' module contains a very large
> number of class methods. This could be better served by a directory
> such as 'test_suite/unit_tests/specific_fns/model_free/' and allowing
> that directory to have a separate unit test model per class methods
> (each containing numerous tests of that one method). As each relax
> function or method will require numerous tests for proper functioning,
> proper throwing of RelaxErrors, etc, the unit test modules could
> become quite large and unwieldy, especially if the self.setUp and
> self.tearDown() methods need to be different for different
> functions/methods.
>
It would be ideal to have one file per because then we can check for
basic coverage and overlooked unit tests. However there is nothing to
stop you adding imports to auxiliary classes to carry out the individual
tests....
See my post in response to Chris' response to your post that I'm now
responding to - if that makes sense! Otherwise:
https://mail.gna.org/public/relax-devel/2007-03/msg00010.html
(Message-id:
<1173248473.29411.21.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>).
Cheers,
Edward
Re: r3080 - /1.3/test_suite/unit_tests/unit_test_runner.py