Working with the Program Tester

Instructions for those homework assignments meant to be tested by the Program Tester:

For such an assignment, you'll be shown sample test input, and the corresponding correct answers for that input.  However, the Program Tester will likely test your program with more extensive input, which will not be revealed to you.  As you're debugging your program, test it with the sample input and make sure it provides the correct output.  You may then want to test your program with more extensive input to insure that it will be robust enough when the Program Tester gets its claws on it.

You will have the opportunity to run the Program Tester yourself on your program and received the Tester's results.  You'll be able to do this any number of times.  You'll also be able to see a log of previous attempts.

Programming restrictions:

  1. Your entire program must be inside the file you submit to the homework server, except for libraries you import (you cannot import other code files you've written).

  2. The first line of your file must be:
    #! /usr/bin/python
    (if you want Python 2.7.12)
    or
    #! /usr/bin/python3
    (if you want Python 3.5.2)

  3. The Tester limits the libraries you're allowed to import.  At minimum you'll be allowed to import the sys library -- in order to obtain the command-line arguments.  The assignment's instructions will show you the exact lines you may use to import libraries.  You do not need to import all of them, if you don't want to.

  4. The answers your program calculates must be written to an output file.  The filename will be provided as a command-line argument.

  5. The assignment's instructions will also tell you the maximum amount of CPU time that your program will be allowed to use.  This is to insure efficient coding.  Your program will be automatically terminated if it exceeds this maximum.  There is also a maximum elapsed time restriction, typically twice the CPU time allowance.

Assume that the Program Tester will always provide you with valid input, the correct number of arguments, etc. -- in other words, you do not need to bulletproof your program against mistakes by the Tester.  But be careful in reading the assignment instructions -- for instance, if it says that you'll be given zero or more fleeps, do not assume you'll get at least one fleep.


Let's take a simple example:  Suppose the task is to copy a selected number of lines from an input file to the output file, where the line numbers that are selected will be given as command-line arguments.  You'll create a program called (let's say) fred.py to do this.  You'll be allowed to include "import sys" only.  The Tester will create the input file and will choose the line numbers (numbering starting at 0) to copy, and will call your program in the following way:

$ python fred.py  dweedle_input.txt  bozo_out.txt  0 18 7

This means that your program should read the input file "dweedle_input.txt", and copy the first, 19th and 8th lines to the output file "bozo_out.txt" in that order.

Here's one possible solution for this assignment:

 
#! /usr/bin/python

import sys

def main():
    # input filename will be in sys.argv[1], and output filename in sys.argv[2]
    inlines = open(sys.argv[1],'r').read().split('\n')
    fout = open(sys.argv[2],'w')

    outlines = []
    for arg in sys.argv[3:]:
        line_number = int(arg)
        outlines.append(inlines[line_number])
    fout.write('\n'.join(outlines))
    fout.close()

main()

Once you've submitted this program to the homework server, you can  go to the View Homework tab, and you'll see something like this (though, of course, your submissions will never be late):

View Homework with ProgramTest and LogView buttons


Then, pressing the "Test program" button will test your program, show you the immediate and also previous results.  Pressing "Previous attempts" will not test, but show previous results.

Note:
In the example below, this student's program actually passed the test 4 times (the history of the tests is in reverse chronological order).  Why he would go on after the program Passed the test the first time, break his program, debug it, break it again and debug it again, and then not trust the Program Tester and retest it, demands a psychological explanation.  None was forthcoming.