Edward d'Auvergne wrote:
On Tue, 2007-03-06 at 09:49 +0000, Chris MacRaild wrote:
On Tue, 2007-03-06 at 08:44 퍍㐙ꫲ S. Thompson wrote:
Edward d'Auvergne wrote:
snip
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....
Although I take the point about multiple tests, setUps and tearDowns per
method, I'd generally suggest that if the unit test file is getting too
unwieldy, the related module probably is too. So perhaps we should
enforce this rule, and split modules when neccessary, not split unit
test files. (still more work, still more breakages, but that might be
the cost of a manageable code base)
We could have multiple test case classes derived from TestCase within
the single module file (corresponding to the single relax source
file). That way we can, if needed, have one class per function. I
think this is really important as the data structures, etc that need to
be created for that one function will be different to what is needed
for another function (if common self.setUp() and self.tearDown()
methods are needed for different functions, we can simply use
inheritance or the same class). For example the setUp() for the
'calc_jw()' function of the module 'maths_fns.jw_mf.py' may need to be
different to that of the subsequent function 'calc_S2_jw()' (then again
maybe not). In fact each of the 128 functions in that single module
may need different setUp() and tearDown() methods (that code was an
absolute nightmare to debug back in 2003, but this setup is very
important for numerical efficiency). A better example might be the
'self.execute()' and 'self.create()' methods of the module
'generic_fns.dasha' which execute Dasha and create Dasha input files
respectively. The tearDown() method for the input file creation tests
will require the deletion of the temporary input files whereas
tearDown() for Dasha execution will be different.
Hi Ed
Setup and teardown whould only be for common stae between a set of
unit tests... os function specific setup and teardown whould go in the
inviviual functions. If a number of functions share specific setup and
teardown functionality that could go in a separate utiltiy function.
On another note one of the things that the the unit test framework
allows us to do is to return a test suite when we load a unit test from
a file (testsuite and test case are polymorphic)... Obviously this
allows multiple different test_cases or suites to be loaded from one
file.. However. overall i agree with chris that if the the files are too
complex they should be split
As for splitting up large modules such as the 66 method, 5701 line
'specific_fns/model_free.py' file, I've been playing around with a few
ideas. I have committed to the 1.3 repository line a change which does
not affect program operation in any way but lays down a foundation for
the breaking up of the model_free.py file
(https://mail.gna.org/public/relax-commits/2007-03/msg00029.html). This
change introduces the directory 'specific_fns/model_free/' while still
retaining the module namespace of 'specific_fns.model_free' by using
import statements in the directory's '__init__.py' file. I've borrowed
this concept from the Python site-packages, especially the Numeric and
scipy modules.
note numeric and scipy (especially) do carry some baggae and have code
bases which are known to be 'tricky'
This foundation can be used to split up the old module
into more manageable, multiple smaller modules, hence simplifying
this code and the future unit test code. The idea should be perfectly
compatible with the possible future conversion of the class methods
into module functions, if this is desired.
I can see a problem here, ideally modules and file structures should
mirror each other otherwise you add an extra layer of structure anf
complication understanding the source code base. I t would be better
break and complicate things by moving them than to make the code base
more complicated
regards
gary
Cheers,
Edward
_______________________________________________
relax (http://nmr-relax.com)
This is the relax-devel mailing list
relax-devel@xxxxxxx
To unsubscribe from this list, get a password
reminder, or change your subscription options,
visit the list information page at
https://mail.gna.org/listinfo/relax-devel
.
--
-------------------------------------------------------------------
Dr Gary Thompson
Astbury Centre for Structural Molecular Biology,
University of Leeds, Astbury Building,
Leeds, LS2 9JT, West-Yorkshire, UK Tel. +44-113-3433024
email: garyt@xxxxxxxxxxxxxxx Fax +44-113-2331407
-------------------------------------------------------------------
Re: Multiple test cases and the splitting up of large modules.