Testing & Autograders

The project uses three complementary kinds of checking.

Local public tests

Run the supplied public test programs while developing. They are designed to catch interface, correctness, verifier, bound, and basic scalability problems before submission.

The exact commands and useful options are collected in Quick Reference.

Gradescope

Gradescope uses additional tests that follow the same documented interfaces and input formats. The hidden tests are intended to verify correctness independently rather than reward solutions that are tailored only to the public examples.

Checkpoint pages identify which requirements are checked mechanically and which are reviewed by the instructor.

Course-owned versus student-owned code

The project distinguishes between course infrastructure and student implementations:

src/course/     course-owned
src/student/    student-owned

Local tests can help detect accidental changes to course-owned files. The authoritative grading environment may also use its own copy of course infrastructure so that the algorithms being assessed are evaluated against the documented project contract.

A productive development cycle

A typical cycle is:

make one algorithmic change
    ↓
run one small instance
    ↓
run the relevant public tests
    ↓
inspect the result
    ↓
make the next change

Use the benchmark runner for experimental evidence after the implementation is stable; do not use large benchmark sweeps as a substitute for small correctness tests.