unitest with python curses app

Discussion in 'Python' started by Brian, Feb 20, 2004.

  1. Brian

    Brian Guest

    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.
     
    Brian, Feb 20, 2004
    #1
    1. Advertising

  2. At some point, Brian <> 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
     
    David M. Cooke, Feb 20, 2004
    #2
    1. Advertising

  3. Brian

    Brian Guest

    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.
     
    Brian, Feb 21, 2004
    #3
  4. At some point, Brian <> 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
     
    David M. Cooke, Feb 22, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Guido
    Replies:
    6
    Views:
    901
    Guido
    May 5, 2004
  2. Matthew Alton

    Serious Python/Curses Wierdness

    Matthew Alton, Sep 18, 2004, in forum: Python
    Replies:
    0
    Views:
    530
    Matthew Alton
    Sep 18, 2004
  3. Jean-Paul Calderone
    Replies:
    2
    Views:
    439
    Joel Hedlund
    Feb 9, 2006
  4. Zebee Johnstone

    scripting a curses app

    Zebee Johnstone, Mar 3, 2005, in forum: Perl Misc
    Replies:
    2
    Views:
    133
    Zebee Johnstone
    Mar 3, 2005
  5. Joseph L. Casale

    Unitest mock issue

    Joseph L. Casale, Feb 14, 2014, in forum: Python
    Replies:
    0
    Views:
    52
    Joseph L. Casale
    Feb 14, 2014
Loading...

Share This Page