CuraCourseAt a glance
Code Grading runs the learner’s program in a sandbox and compares stdout to Expected Output. It is not a unit-test framework with assertions — you control the run with Run command, Input (stdin), optional harness Files, and a comparison method.
A test awards full points or zero. Split independent checks into multiple Code Grading items if you want partial credit across tests.
Prerequisites
- A Code Editor activity with a Code Grading rubric item. See Add rubric items (manual, AI, and code grading).
Make the run command match the files
The default commands assume main.py or Main.java. If starter files use other names, change Run command or the starter filenames so they agree. A mismatch looks like a student failure.
Environment should stay Same as Starter Code. Grade with the same language the editor uses (Python 3.14 or Java 11). Web Sandbox is for running in the editor, not a separate grading environment on the rubric item.
Use Run Test in the editor after you change input, expected output, or harness files.
Prefer exact match, then relax on purpose
Ignore Case and Ignore Whitespace are on by default. That is usually what you want for intro exercises.
| Comparison method | Use it when |
|---|---|
| Exact match | Output should be determined (the default). Best starting point. |
| Partial match | Extra printed text is OK as long as the expected snippet appears — but the check is bidirectional, so a short student print can also match a longer expected string. Keep expected output distinctive. |
| Regex | You need a pattern (optional groups, either/or). Invalid regex falls back to exact match. Regex does not apply Ignore Whitespace the same way — write the pattern against the real stdout. |
Turn Show diff of actual output and expected output on while you are authoring; leave it on for learners when seeing the diff is part of the feedback you want.
Design stdin tests that cannot be hardcoded easily
- Put each stdin value on its own line (the Input help text: stdin - Put each input on a new line.).
- Prefer values that are not the obvious sample from the prompt, so a program that only
prints the sample fails. - Add more than one Code Grading item with different input/output pairs instead of one giant expected transcript.
Use Files for hidden harnesses
Files on the rubric item are instructor harnesses. At grade time they merge in this order: student → course library → rubric files (later wins). A rubric file with the same path as a student file replaces the student file — useful for a hidden tester, dangerous if you accidentally overwrite main.py.
That is separate from the Code Editor’s Hidden Files / Read-Only Files on starter code, and from the course code editor library.
Typical pattern: learners implement a function in a named file; your rubric Files add a main (or test runner) that calls it and prints a stable result.
Avoid false failures
Any of these score 0:
- Non-zero exit code
- Any text on stderr (including warnings and debug prints)
- Output that does not match
- Run longer than 30 seconds
- No files submitted
Ask learners not to print debug traces to stderr. In Python, avoid print(..., file=sys.stderr) and be careful with libraries that warn on stderr. If the program should print a prompt, include that prompt in Expected Output or have the harness print only the graded line.
Partial credit and AI
Each Code Grading item is all-or-nothing. For “passed 2 of 3 tests,” add three items (for example 1 point each) rather than one 3-point item.
Use AI Grading on the same Code Editor for style, comments, or approach. AI sees the submitted files as text; it does not re-run the program. See Best practices for AI grading.
Use Manual Score when you need a human judgment the tests cannot capture.