Main Demo Page (Python3)

Welcome to the CodeRunner Demo Page

This page is designed to allow users to trial basic CodeRunner functionality. These questions have been embedded into the page with the embed question plugin, however these questions are designed to be use 

If you wish to run these questions, please log in with:
Username: trial
Password: trial

This page is a tutorial introduction to CodeRunner questions from simple write-a-function or write-a-program questions through assignment level questions into advanced customised questions to deal with special situations like GUI programming.

Python3 is used throughout this quiz. If you're not a Python3 programmer you can still look through the range of questions that can be asked. With few exceptions, similar questions can be asked in all supported languages (Python3, Python2, Java, C, C++, PHP, JavaScript, Octave, Pascal) though you might have to write your own prototypes for many of those.

As this page is not technically a quiz, no filled answers will be stored.

If these questions were implemented in a quiz, as a user, when you submit the whole quiz at the end, you can review your answers and see the author's sample solutions. This is a standard Moodle feature; the quiz administrator can choose whether or not to display so-called "right answers", and various other information at various phases during the quiz.

We start with write-a-function questions, for which the student must submit a function satisfying the given specs. Since the student's code is run before the test code is run, the student's submission can always include additional support functions if necessary, so the specified function can be almost arbitrarily demanding, such "write a function that compiles a given source file in language X".

All the questions on this page are included in the samples folder in the CodeRunner repository at https://github.com/trampgeek/CodeRunner.

Write-a-program questions

Write-a-function questions are convenient because we can specify the input data and the output result without the complexities of having to specify the formats of input and output files. All the same, for larger tasks like assignments, "write a program" questions are the norm. Typically these ask students to read from standard input and write to standard output. Learner programmers think of these as keyboard and screen but on a quiz server data is of course taken from files. For testing such programs, the question author supplies standard input and specifies the expected output just as for write-a-function programs. The question author can also attach support files to the question; these are loaded into the execution environment at run time and can be used for input data or additional code, libraries etc, depending on the type of question.

A problem with running program that take their standard input from a file rather than the keyboard is that the input data does not get echoed to the screen. This is confusing for learner programmers. Our standard Python program question type replaces the usual Python input() function with one that does echo its input to standard output, so that the student sees the same output as when they run from the keyboard.

A note on templates

The preceding Skool-z-Kool question used the basic Python3 question type, but with the built-in input function replaced by one that echoes the characters read from standard input. This is achieved by customising the question's template in the question-authoring interface. The template is a way to specify how the student's submission, the per-test-case code and any other testing code are combined to define the program to be run in the sandbox. For the above question, the template was just

__saved_input__ = input
def input(prompt=""):
    result = __saved_input__(prompt)
    print(result)
    return result

{{STUDENT_ANSWER}}

{{TEST.testcode}}

The effect is just to re-define the input function, run the student code and then run the test code.

If you find yourself using such a template repeatedly, you would normally make it into a new question type, such as python3_with_input, by defining the question as a prototype. See the CodeRunner documentation for details.

Improving Skool-z-Kool

A problem with the preceding version of Skool-z-Kool is that it while it suggests that students should write the code with support functions, they are not forced to do so. Beginner programmers often need more encouragement than that!

The first improvement we can make to the question is to use pylint to check the submission before running it, as was done with the second version of print_name. In our introductory programming course we turn on pylint checking almost from the start. Our python_cosc121 question type, used for most questions in the course, allows us to configure pylint differently for each question by using template parameters. In a question like Skool-z-Kool we would typically limit the length of any one function to around 10 - 20 lines, which pretty much forces students to use functions.

Particularly earlier on in a course we might wish to constrain the students even further, so that they are forced to use a particularly functional decomposition. That of course requires that we specify the support functions they must use and also that we must test those functions separately. A common way of achieving that is to precede the main program test question with a set of write-a-function questions, one for each support function we wish them to write. An alternative approach is that taken by the following variant of Skool-z-Kool, which presents the students with a skeleton of the program. They then have to fill in all the blanks to get the program working. Note that in our teaching environments students always have a full Python development environment available to them while doing CodeRunner questions, even in tests and exams. They are expected to develop and test their code before submitting it to the quiz server.

Other question types

The above questions have asked students to write a function (possibly with additional support functions) or to write a whole program. The remaining questions show a few other forms of question. Essentially you can ask any question you like subject to two requirements:

1. The student submission is a single piece of text (usually, but not necessarily, program code)
   
2. You, the question author, are able to write a program that can assess the correctness of that submission.