LeetCode Custom Testcases: What Run Code Actually Executes

The short answer: custom input only affects Run Code

On a LeetCode problem page, the Testcase pane (sometimes labeled "Custom Input") is the input that the Run Code button uses. It does not feed Submit. Submit always runs the problem's hidden suite. The practical workflow is: put an edge case in the pane, press Run Code, read the output; when you are satisfied, press Submit for the real verdict.

Nothing typed in the pane is saved with your submission or counted toward acceptance. It is a scratch input box attached to a hosted judge.

How the pane reaches your function

Each problem defines a serialization for its arguments. The judge parses the text you typed into the same argument types the problem's entry point expects, then calls that entry point — the same one Submit calls. Two shapes cover most problems:

• Positional, one value per line. The first line is argument one, the second is argument two, and so on.
• JSON-like literals. Arrays, strings, numbers, booleans and null written in a JSON-ish syntax, often on one line.

Because the parser is problem-specific, the exact delimiter matters. A missing bracket or an extra blank line can produce a parse error instead of a wrong answer, which is a different failure mode and worth recognizing quickly.

Worked example: a two-sum style case

Suppose the signature is twoSum(nums, target) and the sample input is [2,7,11,15] on one line and 9 on the next. To probe duplicate handling, replace the pane contents with:

[3,3]
6

A correct zero-based solution should return [0,1]. The reference implementation below is the kind of code that produces that output:

def twoSum(nums, target):
    seen = {}
    for i, n in enumerate(nums):
        if target - n in seen:
            return [seen[target - n], i]
        seen[n] = i
    return []

Run Code on that input should display [0,1]. I have not executed this against the live judge; treat the expected output as the format you compare against, not as a recorded result.

Note what the case actually tests: the duplicate 3 must be matched with a later index, so the map entry has to be written after the lookup. That is the kind of bug a sample case with distinct values hides.

Linked lists, trees and other structured arguments

For node-based problems, the pane usually takes array notation and the judge builds the structure before calling your function. A list [1,2,3] becomes three linked nodes; a tree is often given in level order with null marking absent children, for example [1,2,3,null,4]. Your function still receives a node reference, not the array, so code that expects the raw text will fail.

Design and class problems

Problems that ask you to implement a class usually serialize a sequence of operations and their arguments, with expected outputs listed separately. Run Code replays that sequence rather than making a single call. If the pane shows two parallel lists — operations and arguments — both must stay aligned, or the replay will call the wrong method.

Run Code versus Submit

Aspect	Run Code	Submit
Input used	Whatever is in the Testcase pane	The problem's hidden test suite
Number of cases	One, or one operation sequence	Many, including edge and large cases
Effect on progress	None; not recorded as an attempt	Produces the accepted or rejected verdict
Limits applied	Problem time and memory limits	Same limits, applied per case

Limits worth knowing before you rely on it

• It is not a substitute for hidden tests. Passing a custom case tells you one input works. Acceptance requires the full suite.
• Custom inputs are not persisted. Reloading or navigating away can lose them, and they are not attached to your submission.
• Limits still apply. A very large custom input can time out or be rejected before your algorithm is fairly measured.
• Not every problem accepts arbitrary input. Interactive, database and shell problems may use a different pane or format, or none at all.
• Percentile numbers are noisy. Runtime and memory rankings depend on judge load and language, so do not tune against a single Run Code measurement.
• Treat the pane as public input. Do not paste secrets, tokens or personal data into a hosted judge.

Common mistakes

1. Editing the pane, then pressing Submit. The custom input is ignored and the hidden suite runs. If your result looks like the sample's, this is the likely cause.
2. Malformed serialization. Missing brackets, wrong delimiters or stray blank lines yield a parse error, not a wrong answer. Read the error text before changing your algorithm.
3. Assuming the output format. If the expected output is a list but your function returns a tuple or a string, the comparison fails even when the logic is right.
4. Only testing the happy path. A single sample-shaped case rarely exposes off-by-one or duplicate-handling bugs.
5. Confusing a local pass with correctness. Run Code exercises your code on the judge, but only for the input you supplied.

A small custom-case set and how to verify it

Keep four cases per problem shape and reuse them across attempts:

1. Empty or minimal input: empty array, single node, zero-length string.
2. Single element, to catch index assumptions.
3. Duplicate or repeated values, to catch set-versus-map bugs.
4. Maximum-size shape, to see whether the approach is fast enough.

To confirm the feature behaves as described on your current page:

1. Open the problem and locate the control that feeds Run Code. If the label differs from "Testcase", use whichever control the Run button reads from.
2. Enter a trivial input whose answer you already know and check the displayed output matches the expected format.
3. Enter one deliberately malformed input and observe how the parse error is reported. That tells you which failures are yours and which are the parser's.
4. Press Submit without changing the pane and confirm the custom input had no bearing on the verdict.
5. Read the problem's input-format section for the serialization that problem uses, since it can differ between problem types.

Version note: LeetCode's pane labels, serialization rules and the set of problem types that accept custom input can change between releases. Confirm current behavior on the problem page before depending on a specific label or delimiter.