"finally" for unit test

Duncan Booth duncan.booth at invalid.invalid
Fri Mar 23 08:19:15 EDT 2007


"killkolor" <gabriel.hase at gmail.com> wrote:

> I have a unittest framework that tests a single function that in turn
> works with files (takes input and outputs in the same file, no return
> values).

I would want to split that function into two:

a) one which does the processing, but not working with a file,
b) and one which handles reading and calls the processing function and then 
writes the file. The function it calls would be passed in as an optional 
parameter and defaults to function (a)

Then you need two sets of tests:

 one to test the action of reading data from a file and then rewriting the 
output in-place, but you just pass in a mock function for the processing 
which can assert that it saw the expected inputs.

 and as many tests as you want for the processing, but no annoying files to 
get in the way.

If you really cannot have the processing without reading from a file, then 
let it take two files, input and output as parameters, and have the (b) 
function choose between calling it with separate input/output files or 
creating a temporary file which is renamed to replace the original on 
completion. Then at least you can read directly from the test inputs 
without ever needing to write them.



More information about the Python-list mailing list