mailMultiple test cases and the splitting up of large modules.


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Edward d'Auvergne on March 07, 2007 - 07:24:
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.

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.  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.


Cheers,

Edward




Related Messages


Powered by MHonArc, Updated Thu Mar 08 09:40:24 2007