# Code grading

> 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…

Source: https://www.curacourse.com/help/best-practices-for-code-grading

## At 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 `print`s 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](https://www.curacourse.com/help/best-practices-for-code-grading).

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.

## Related articles

- [Course blocks: code editor library](https://www.curacourse.com/help/course-blocks-code-editor-library)
- [Rubrics & scoring modes](https://www.curacourse.com/help/rubrics)
- [Grade a lesson with Lightning Grader](https://www.curacourse.com/help/grade-a-lesson-with-lightning-grader)
- [Add rubric items (manual, AI, and code grading)](https://www.curacourse.com/help/add-rubric-items-manual-ai-and-code-grading)
- [Best practices for AI grading](https://www.curacourse.com/help/best-practices-for-ai-grading)