Leveraging LeetCode’s Custom Test Pane for Rapid Local Debugging

Why the Custom Test pane matters

When you start solving a LeetCode problem, the hidden test suite is invisible until you click "Submit". If your solution fails, you only see a generic "Wrong Answer" message, which forces you to guess what went wrong. The Custom Test pane lets you run your code with any input you choose, see the exact output, and measure execution time and memory usage before you submit. This tight feedback loop can save minutes of debugging per problem.

How the pane works

After you select a language in the editor, a tab labeled "Custom Test" appears below the code area. It contains three fields:

• Standard Input – the data your program reads from stdin (or the equivalent in your language).
• Expected Output – optional; you can fill it to compare against your program’s stdout.
• Run Code button – sends the code and input to LeetCode’s sandbox, which uses the same compiler/runtime versions as the judge.

When you press "Run Code", the sandbox returns:

• Program output (stdout)
• Execution time (in milliseconds)
• Memory consumption (in megabytes)
• Any runtime errors or sandbox‑limit messages (e.g., "Time Limit Exceeded" or "Memory Limit Exceeded")

These metrics mirror those shown after a real submission, so you can gauge whether your solution is likely to pass the hidden tests.

Worked example: Two‑Sum

Consider the classic "Two Sum" problem: given an array of integers nums and a target target, return indices of the two numbers that add up to target. Below is a straightforward O(n²) solution in Python 3.

from typing import List

def two_sum(nums: List[int], target: int) -> List[int]:
    for i in range(len(nums)):
        for j in range(i + 1, len(nums)):
            if nums[i] + nums[j] == target:
                return [i, j]
    return []

# The Custom Test pane expects the solution to read from stdin and write to stdout.
# We'll adapt the function to a simple driver.
if __name__ == "__main__":
    import sys, json
    data = json.load(sys.stdin)
    nums = data["nums"]
    target = data["target"]
    ans = two_sum(nums, target)
    print(json.dumps(ans))

To test this code:

1. Open any LeetCode problem (e.g., "Two Sum"), select "Python 3" as the language.
2. Scroll to the bottom and click the "Custom Test" tab.
3. In the "Standard Input" field, paste a JSON object that matches the driver’s expectation, for example:

{"nums": [2, 7, 11, 15], "target": 9}

1. Leave "Expected Output" blank (or fill [0,1] if you want a quick check).
2. Click "Run Code".

The sandbox will return something like:

Output: [0,1]
Time: 4 ms
Memory: 12.3 MB

You can now experiment with edge cases, such as duplicate numbers or large inputs, without leaving the problem page. If you notice the runtime climbing toward the limit, you know to reconsider the algorithm before submitting.

Trade‑offs and limitations

The Custom Test pane is a powerful debugging aid, but it does not replace the hidden test suite:

• No guarantee of acceptance – Passing your own test cases does not ensure the solution satisfies all hidden constraints.
• Sandbox variability – LeetCode occasionally updates the compiler flags or runtime environment; a solution that runs fine today might behave differently after a platform update.
• Input size limits – The sandbox enforces the same time (≈2 s) and memory (≈256 MB) limits as the judge, but very large custom inputs may still be truncated by the browser before they reach the sandbox.

To mitigate these risks, treat the Custom Test pane as a pre‑flight check: use it to verify correctness and performance on a diverse set of hand‑crafted cases, then rely on the final submission to confirm acceptance against the hidden suite.

Actionable closing

Next time you start a LeetCode problem, make the Custom Test pane your first stop after writing a draft solution:

1. Write a minimal driver that reads JSON from stdin and prints the answer.
2. Create a few input files covering typical, edge, and stress cases.
3. Run each case, inspect output, time, and memory.
4. If any case fails or exceeds limits, refine the algorithm before hitting "Submit".

By integrating this step into your workflow, you reduce guesswork, catch inefficiencies early, and make the submission process smoother.