Using LeetCode’s Custom Test Editor to Validate Solutions Before Submission

Why hidden test failures stall your progress

When a solution passes the sample tests but fails on LeetCode’s hidden suite, you lose time guessing which input caused the mismatch. Without a way to run your own scenarios, you might resort to adding print statements, resubmitting, or searching forums—each step adds friction.

Opening the Custom Test editor

In any problem’s code editor you will find a tab named Custom Test. Clicking it opens an area where you can type raw input, select a programming language from a dropdown, and press Run Code to see the program’s output together with runtime and memory usage.

Creating, saving, and reusing test cases

Type the input exactly as the problem expects (for example, for Two Sum the array [2,7,11,15] followed by a newline and the target 9). Choose your language, hit Run Code, and observe the output. If the result matches the expected output, click the save icon to store the case; the test case remains available for later sessions and can be edited or deleted as needed.

Worked example: validating Two Sum

1. Open the Two Sum problem and select the Custom Test tab.
2. In the input pane, paste:

   [2,7,11,15]
   9

3. Select Python 3 from the language dropdown.
4. Press Run Code.
5. The right pane shows the output [0, 1] (or the format your solution returns) together with runtime and memory usage.
6. Click the save icon to keep this case for future runs.

Now try an edge case with duplicate numbers:

[3,3]
6

Select the same language and run again; the correct output should be [0, 1]. If your code returns something else, you have isolated the bug without submitting.

Trade‑offs and limitations

The custom test sandbox enforces the same time and memory limits as the judge, but the set of pre‑installed libraries may differ slightly. Consequently, a solution that relies on a niche library could behave differently in a custom run versus a final submission. More importantly, custom tests never influence your score; they are purely for local validation, so you cannot bypass hidden tests by crafting a perfect case.

Actionable closing

Before you hit Submit, run at least three custom tests: the official example, a simple edge case you devise, and a random large‑input case to stress performance. Compare the reported runtime/memory with the numbers from your last submission; if they are in the same ballpark, you can be confident the sandbox is behaving like the judge. Incorporating this quick validation loop cuts down on blind resubmissions and sharpens your debugging skills.