"finally" for unit test
duncan.booth at invalid.invalid
Fri Mar 23 16:21:50 CET 2007
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.
More information about the Python-list