"finally" for unit test

[Duncan Booth]

Jorgen Grahn <grahn+nntp at snipabacken.dyndns.org> wrote:

> On 23 Mar 2007 12:19:15 GMT, Duncan Booth
> <duncan.booth at invalid.invalid> wrote: 
>> "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,
> 
> 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.