unitest with python curses app

[Brian]

Hello;

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?)

The curses part of the program seems to affect unittest's writing of the
report. The screen is not what the report expects, so a lot of
information is in the wrong place after the program exits. (I actually wrap
the calls into the
curses library with curses.wrapper() in an attempt to restore the display
properly after the program exits -- to no avail. I guess the problem is
that unittest writes to the display while curses has control, not just
just afterwards.

How do I handle test reporting for a graphical (curses) application? I
would really like to read or capture the report on screen after the
program exits.

Many thanks,

Brian.

[David M. Cooke]

At some point, Brian <ba***@sympatico.ca> wrote:

Hello;

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?
The curses part of the program seems to affect unittest's writing of the
report. The screen is not what the report expects, so a lot of
information is in the wrong place after the program exits. (I actually wrap
the calls into the
curses library with curses.wrapper() in an attempt to restore the display
properly after the program exits -- to no avail. I guess the problem is
that unittest writes to the display while curses has control, not just
just afterwards.
Right. Pain in the ass to debug that stuff too.
How do I handle test reporting for a graphical (curses) application? I
would really like to read or capture the report on screen after the
program exits.

Probably setting sys.stdout and sys.stderr to your own file objects
would work before calling unittest.main(). Something like this would
give the output after it runs:

import sys
from cStringIO import StringIO
import unittest

....test cases...

if __name__ == '__main__':
old_stdout, old_stderr = sys.stdout, sys.stderr
sys.stdout = StringIO()
sys.stderr = StringIO()
unittest.main()
old_stdout.write(sys.stdout.getvalue())
old_stderr.write(sys.stderr.getvalue())

--
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm(at)physics(dot)mcmaster(dot)ca

[Brian]

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.)

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:

t 5 5 -acharset +abold ... (other attribute codes follow)
h 5 6 -acharset +abold ... (other attribute codes follow)
.... (other cell records follow)

With respect to the first record: "t" is the character at [y ,x] ==
[5,5]. It is not from the alternate
character set (-acharset). It is rendered in bold (+abold). Other
attributes follow the same pattern: +attrName for on and -attrName for
off. Foreground and background colour numbers (or names -- I can't
remember) appear at the end.

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.

Brian.

[David M. Cooke]

At some point, Brian <ba***@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