[TIP] {Disarmed} Re: Testing multi-threaded applications

Raphael Marvie raphael.marvie at lifl.fr
Fri May 11 02:12:29 PDT 2007

On May 10, 2007, at 7:18 PM, Bernhard Mulder wrote:
> That has at least the advantage of being very systematic.
> There are two things which I dislike about this solution:
> 1. This can lead to a long list of parameters passed around, and  
> obscures the distinction of the parameters which are needed for the  
> algorithmic part, and the once introduced only to satisfy testing  
> requirements. I would prefer for the testing artifacts to be out of  
> the way as much as possible when I read code to understand how it  
> works.

I get you point, in the meantime I do not consider a timeout only as  
a testing artifact. I also consider that such an element is more an  
"object property" than a hard coded value, thus should be  
configurable easily (this is for the timeout value part). Comparing  
our proposals the difference lays mostly in the indirection.

> 2. If you put the testing parameters into some structure (dict or  
> class) to avoid the "testing clutter", and keep the number of  
> parameters at a reasonable number, you are essentially back to the  
> solution I proposed.

Well, when parameters have a default value I am not bothered by their  
number, but this is purely personal. I consider them as object  
properties and not test related information.

> 3. If you read the call to sleep, "self.sleep", you have to  
> remember that self.sleep is really time.sleep, except for testing.

but as my __init__() sets this value, the reader know what it mean by  
default. On this I do not see the difference between our two solutions.

> My first attempt was to put all such system functions into one  
> module. Something like:
> Systeminterface.py:
> class time(object):
>     from time import sleep, time
> However, the class definition transforms function into methods, and  
> I have to add extra code to transform the method back into a  
> function. I now think it is simpler to make Systeminterfaces into a  
> module, and then create a time module as a part of that package.  
> Systeminterfaces.mytime would simply be:
> from time import sleep
> [Not sure if I can name this module time and somehow get the time  
> module from the distribution in the import statement, instead of  
> the current module].
> Then, to use sleep in a module, I can say:
> from SytemInterfaces.mytime import sleep
> My current code is something like this:
> from SystemInterfaces import time
> sleep = time.sleep

yes but you do not know what is the real implementation behind neither.

> >To some point, externalizing the opening of files.
> I suppose by "externalizing the opening of files" you mean  
> introduce a class which handles the interface to the file system,  
> like creating directories, querying the file system, etc?

nope. I meant if function x needs to write to something that may be a  
file I prefer to pass an object that provides the write function and  
do the opening outside of the function itself.

def write_data_to_file(self, filename):
     """Open filename for writing and use write_data for completion"""
     f = open(filename, 'w')

def write_data(self, output):
     """Write data to the provided output object.

     output has to provide a write() function.
     # my complex algorithm
     # ...

So that each function has a clean responsibility and write_data can  
be easily tested and used  with something else that a file if needed.

This express my 'divide to conquer' / 'the best method is the one  
that does nothing' implementation and design strategy.


Raphael Marvie, PhD                http://www.lifl.fr/~marvie/
Maître de Conférences / Associate Professor  @  LIFL -- IRCICA
Directeur du Master Informatique Professionnel spécialité IAGL
Head of Master's in Software Engineering     +33 3 28 77 85 83

More information about the testing-in-python mailing list