Home Original page

unitest with python curses app

David M. Cooke cookedm+news at physics.mcmaster.ca
Sat Feb 21 23:07:54 EST 2004 
At some point, Brian <balex at sympatico.ca> wrote:
> On Fri, 20 Feb 2004 16:52:07 -0500, David M. Cooke wrote:
>>> I'm writing a program with curses in python and having a bit of trouble
>>> understanding how to use unittest. So far, I have used testing
>>> successfully -- as long as the report goes to stdout (or does unittest
>>> write to stderr?)
>> 
>> I'm interested: how are you unit testing curses routines? Are you
>> testing just the output routines, or are other non-curses routines being
>> called?
>  
> Unfortunately, only the routines that did not involve the curses module were
> easy to test. Judging from your message, I think you inferred this.
> (Indeed, you seem to have lived it.)

Only recently -- I've been trying to port a DOS-era game written in
Turbo Pascal to run under Unix with ncurses. Debugging is a pain --
nevermind curses, but gdb doesn't work nicely with GNU Pascal.

> However, I did build a dump-to-text feature into an object that wraps
> all curses newwin objects. When <obj>.dumpCells() is called, a text record for
> each cell in the newwin is generated. It looks something like this:
[snip]
> These human readable-records could be used to build test cases for the
> screen outputs. I haven't done it yet, though. I imagine such a test
> comparing the results of a call to .cellDump() to some stored (and
> correct, hopefully) result in a file.

Good idea. You could make a 'screen painter' to mock up what the
screen should be, to make it easier to generate the correct screens.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm(at)physics(dot)mcmaster(dot)ca
More information about the Python-list mailing list