Test case format

Every test case is two JSON objects: the input your function is called with, and the expected output it should return. This page is the reference for getting them right.

The shape

Input is an object whose keys are your parameter names. Not an array, not positional — keys, matching the names on the Function tab exactly, including case.

Expected output is an object with a single result key holding the return value.

For a function sumRange(nums: int[], target: int) -> int:

{ "nums": [1, 2, 3, 4], "target": 3 }

{ "result": 6 }

The output wrapper is not decoration — the generated harness prints the return value as {"result": …} in every one of the 21 languages, so that is the shape your expected value is compared against.

For a void function the expected output is an empty object, {}.

Examples by return type

The two editors

Each test case can be edited as raw JSON or through the visual builder, toggled per case.

The visual builder reads your parameter list and renders a field per parameter with the right control for its type, which removes a whole class of typos — a misspelled key, a missing brace, a string where a number belongs. It is the better default, especially for arrays.

You cannot switch a case to visual mode while its JSON is invalid, because there is nothing to render. Fix the JSON first; the editor says so rather than silently discarding it.

There is also a fill-from-signature action that writes a skeleton with every parameter present and an empty value of the right type. Starting from that is faster than typing the braces, and it cannot misspell a key.

Public and private

Each case is marked Public or Private.

• Public cases are shown to the candidate as worked examples. They explain the problem better than another paragraph of prose.
• Private cases are hidden and are what the score is really based on.

Have at least one public case, so candidates can confirm they understood the question, and enough private ones that hardcoding the public answers gets nowhere.

Private cases are where you put the edge cases: empty input, a single element, duplicates, negative numbers, the maximum size you claimed to support. A candidate who passes every public case and fails the empty-input case has told you something real.

How output is compared

Not as text. Both sides are parsed as JSON and compared semantically, which means:

• Key order does not matter. {"a":1,"b":2} equals {"b":2,"a":1}.
• Whitespace and formatting do not matter. Pretty-printed and minified are the same value.
• Whole-number floats are normalised. 5.0 equals 5. This is deliberate: languages disagree about whether an integral double prints as 5 or 5.0, and without normalisation the same correct answer would pass in Python and fail in Java.

GOTCHA: floats are compared exactly

Normalisation applies only to whole numbers. 0.1 + 0.2 produces 0.30000000000000004, and that is not equal to 0.3.

If your function returns a non-integral float, you will eventually fail a correct solution over the last bit. Avoid it: have the function return a value rounded to a stated number of decimal places and say so in the description, or restructure the problem to return an integer — cents rather than euros, or a count rather than an average.

GOTCHA: invalid JSON silently becomes a string comparison

If either side fails to parse as JSON, the comparison falls back to comparing the two as trimmed strings. It does not error.

A malformed expected output therefore does not announce itself. It quietly makes the case unpassable unless the candidate's output happens to match your typo character for character. The editor flags invalid JSON while you type — do not save past that warning.

The trap that costs the most

Renaming a parameter breaks every existing test case, because the input keys no longer match. Nothing warns you: the question saves, the harness generates, and every case fails with output that looks like the candidate's mistake.

If you rename a parameter on the Function tab, go through the test cases before saving. This is the single most common way a working question turns into a broken one during an edit.

Verify before inviting

Open the assessment's Preview and solve your own question. Preview runs the real execution path against these exact test cases and creates no attempt.

Solve it correctly and confirm every case passes. Then solve it wrongly on purpose — return the wrong type, or the right answer off by one — and confirm the cases fail. A test case that passes no matter what the candidate submits is worse than no test case, and preview is the only place you will notice.