"finally" for unit test

[killkolor]

hi!

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).
In the unittest class I assign a member with all the names of my
testfiles and a testdirectory. The tests call the function (which
opens and writes to the file) and then opens the file to see if
everything is in order. The problem now is that after each testrun I
have to copy "fresh" files into the testdirectory, since of course the
function already run on all the files and made the changes. So I
implemented a buffering in the unittest functions: buffer the file,
call the function, make the test, write the buffered file back. This
works fine for unittests that do not fail. If a unittest fails though
the function stops and the writing back is never done. Is there
something like a finally for unittest functions? Or could I use
another approach to buffer and write back my files (for each unittest
function)?
thanks!
gabriel

 

[Steven D'Aprano]

The problem now is that after each testrun I have to copy "fresh" files
into the testdirectory, since of course the function already run on all
the files and made the changes. So I implemented a buffering in the
unittest functions: buffer the file, call the function, make the test,
write the buffered file back. This works fine for unittests that do not
fail. If a unittest fails though the function stops and the writing back
is never done. Is there something like a finally for unittest functions?
Or could I use another approach to buffer and write back my files (for
each unittest function)?

A simple approach would be to copy the test files *before* running the
tests, instead of after. That way it doesn't matter if the tests fail or
not: the next run will simply replace the test files with known good
copies, regardless.

 

[Peter Otten]

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).
In the unittest class I assign a member with all the names of my
testfiles and a testdirectory. The tests call the function (which
opens and writes to the file) and then opens the file to see if
everything is in order. The problem now is that after each testrun I
have to copy "fresh" files into the testdirectory, since of course the
function already run on all the files and made the changes. So I
implemented a buffering in the unittest functions: buffer the file,
call the function, make the test, write the buffered file back. This
works fine for unittests that do not fail. If a unittest fails though
the function stops and the writing back is never done. Is there
something like a finally for unittest functions?
TestCase.tearDown()

http://docs.python.org/lib/testcase-objects.html#l2h-5002

Or could I use
another approach to buffer and write back my files (for each unittest
function)?

Rather than restoring the file I would just delete it and use

TestCase.setUp() to make a fresh copy.

Peter

 

[skip]

gabriel> Is there something like a finally for unittest functions?

TestCase instances have setUp() and tearDown() methods:

http://docs.python.org/dev/lib/testcase-objects.html

Skip

 

[Duncan Booth]

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.

 

[killkolor]

I went with the TestCase.setUp() function.
Thanks a lot!

 

[Jorgen Grahn]

I would want to split that function into two:

a) one which does the processing, but not working with a file,

Better to make it work with "a file", in the sense that it works with
file-like objects so you can feed and leech it using StringIO.

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)

/Jorgen

 

[Duncan Booth]

Better to make it work with "a file", in the sense that it works with
file-like objects so you can feed and leech it using StringIO.

I'm assuming, perhaps wrongly, that something which takes input from a file
and produces output into the same file is doing something beyond the simple
interface supported by StringIO. So I was guessing either that something
like FileInput is involved, or seeking and modifying in-place.

Anyway, the principle is the same: you make sure no function does more than
one job, and you make sure that all functions are testable independently.

 

[7stud]

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

That function could cause problems. If your function reads in the
whole file, modifies the data, and then overwrites the file, what
would happen if something unforeseen happened and your program crashed
after writing one line to the file? All the data in memory would go
poof! and your file would contain 1 line it--effectively erasing the
entire contents of the file.