'[Edu-sig] testing interactive loops'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-edu-sig
Subject:    [Edu-sig] testing interactive loops
From:       aharrin () luc ! edu (Andrew Harrington)
Date:       2006-05-23 17:58:13
Message-ID: 44734D35.2030603 () luc ! edu
[Download RAW message or body]

For testing keyboard input loops in a tutorial, the issue with 
__builtin__ should not arise with Crunchy Frog code snippet testing, 
because the snippet is copied into a main module!  I like the idea of 
some marker for the main engine that a doctest is interactive.  Instead 
of the current doctest marker
<pre vlam="doctest">
we might use
<pre vlam="doctestInteractive">
or to indicate delimiters and their replacements we might use
<pre vlam="doctest" inputAfter="'??':'?','::':':'">

and have the engine then change :: and ?? to : and ? and extract the 
input that follows them, and do the input redirection so doctest then works.

Andy

Andre Roberge wrote:

> On 5/16/06, *Andrew Harrington* <aharrin at luc.edu 
> <mailto:aharrin at luc.edu>> wrote:
>
>     We have been discussing testing in tutorials with doctest.
>     There is one place that does not work, I think:  testing an
>     interactive
>     loop, which is a construction I teach in introductory programming.
>
>     It appears that doctest cannot handle interactive input.  I would
>     still
>     like to be able to illustrate a session with interactive input and
>     explicit output at the end, and check it automatically.
>
>     If you just do input redirection and compare the actual output to the
>     desired input, you get messed up because the input is not echoed when
>     you redirect from a file.
>
>     The following does not work, but is the idea you want, to force
>     the echo
>     when stdin become a file:
>
>     orig_raw_input = raw_input
>
>     def raw_input_echo(prompt=""):
>         s = orig_raw_input(prompt)
>         print s
>         return s
>
>     raw_input = raw_input_echo
>
>     def input_echo(prompt=""):
>         return eval(raw_input(prompt))
>
>     This fails because it makes raw_input a global for the current
>     module,
>     but not a built_in, so it fails when you import and use a module using
>     raw_input.
>
>
> How about:  (something totally untested)
> import ah  # module named after you :-)
> ah.raw_input = raw_input_echo
>
> And then you run your tests?...
>
> Andr?
>
>     I guess we could make it work in little code fragment tests, where
>     you
>     append the user's fragment to the code above, in the same module,
>     but it
>     is not a general solution.
>
>     Is there any better way to do this?
>
>     A kludge for tutorial doc tests would be to mark the prompt strings
>     somehow in the tutorial source, for instance making it always end with
>     :: or ?? so the test string can be parsed to find the responses that
>     come after the prompts, and put them in the input file and not in the
>     output file.  For example, the test string
>     ... Sum numbers!
>     ... Enter a number (or 0 to quit):: 3
>     ... Enter a number (or 0 to quit):: 4
>     ... Enter a number (or 0 to quit):: 8
>     ... Enter a number (or 0 to quit):: 0
>     ... The sum is 15!
>
>     might be processed for web display in the tutorial undoubling the ::
>
>     ... Sum numbers!
>     ... Enter a number (or 0 to quit): 3
>     ... Enter a number (or 0 to quit): 4
>     ... Enter a number (or 0 to quit): 8
>     ... Enter a number (or 0 to quit): 0
>     ... The sum is 15!
>
>     and the tutorial parser would also generate an input file
>     3
>     4
>     8
>     0
>
>     and output file
>
>     Sum numbers!
>     Enter a number (or 0 to quit):
>     Enter a number (or 0 to quit):
>     Enter a number (or 0 to quit):
>     Enter a number (or 0 to quit):
>     The sum is 15!
>
>     Then run the code with redirection and compare the desired and actual
>     output.  There still is the issue of the program hanging with the
>     given
>     input ...
>
>     How does regular doctest deal with infinite loops or waiting for
>     nonexistent keyboard input?
>
>
> ??
>  
>
>     Better ideas?
>
>     --
>       Andrew N. Harrington
>       Computer Science Department      Undergraduate Program Director
>       Loyola University Chicago        http://www.cs.luc.edu/~anh
>     <http://www.cs.luc.edu/%7Eanh>
>       512B Lewis Towers (office)       Office Phone: 312-915-7982
>       Snail mail to Lewis Towers 416   Dept. Fax:    312-915-7998
>       820 North Michigan Avenue        aharrin at luc.edu
>     <mailto:aharrin at luc.edu>
>       Chicago, Illinois 60611
>
>     _______________________________________________
>     Edu-sig mailing list
>     Edu-sig at python.org <mailto:Edu-sig at python.org>
>     http://mail.python.org/mailman/listinfo/edu-sig
>
>

-- 
  Andrew N. Harrington
  Computer Science Department      Undergraduate Program Director
  Loyola University Chicago        http://www.cs.luc.edu/~anh
  512B Lewis Towers (office)       Office Phone: 312-915-7982
  Snail mail to Lewis Towers 416   Dept. Fax:    312-915-7998
  820 North Michigan Avenue        aharrin at luc.edu
  Chicago, Illinois 60611          

[prev in list] [next in list] [prev in thread] [next in thread] 