Limitation on Standard Input/Output and Test Cases ?

Limitation on Standard Input/Output and Test Cases ?

de Piriya Utamachant -
Número de respuestas: 1
Hello, 

I'm working on Array Questions which require big amount of input on test cases. I have several questions.
  1. Is there a limitation on the standard input and output of a test case? For example if I would put 1000 integers for standard input and check 1000 integers of Expected output. 
  2. Is there a limitation on number of test cases for one question?
  3. Using Moodle's UI to setup this kind of extensive questions is difficult. Is there any suggestion ? Looks like CodeRunner question can be import/export with Moodle XML format. I'm thinking there could be some external tool to help setting up question in that format ? 

Thank you :D

Piriya


En respuesta a Piriya Utamachant

Re: Limitation on Standard Input/Output and Test Cases ?

de Richard Lobb -

Be default the disklimit sandbox parameter limits output file sizes to 20 MB and the streamsize parameter limits stdout/stderr output to 2 MB. I don't remember any explicit limits on input, though there's always some sort of limit somewhere. But I recall pasting some huge input strings (several MB) into the web interface in the past.

Testing with 1000 integers is under any of those limits.

Likewise, I don't know of any limits on test cases except:

  1. If entering them through the web interface you'll get exhausted long before the limit is reached.
  2. The job still has to run in a few seconds (the default maximum run time on a Jobe server is 50 secs).
  3. The result table will become tediously long to read.
If you're planning on running large numbers of tests you probably want to use a combinator template grader - see the documentation. Then you can run computer-generated tests. Combinator template graders are non-trivial, but straightforward enough once you've got used to how they work. Most of our in-house question types nowadays use combinator template graders because they give you total control over how the code is tested and how results are displayed. I think that would be a much better approach than trying to manage questions via XML files.