Debugging LeetCode Solutions with the Custom Test Case Editor

Why the Custom Test Case Editor Matters

When a solution fails on LeetCode, the first clue is often a "Wrong Answer" badge. The hidden test suite may be exercising an edge case you never considered, or a simple formatting mistake could be causing the mismatch. The custom test case editor lets you run your code against inputs you define, showing the actual output beside the expected one, along with runtime and memory usage. This immediate feedback separates logic errors from presentation issues without affecting your submission status.

Setting Up a Custom Test Case

Below the code editor you will find two text areas labelled "Input" and "Expected Output". Click the "Run Code" button to execute your solution with the supplied data. The result panel displays:

• Actual output produced by your code
• Expected output you typed
• Runtime and memory consumption

If the two outputs match, the test passes; otherwise you see a side‑by‑side diff.

Worked Example: Debugging "Two Sum"

Consider the classic "Two Sum" problem. Your first implementation returns indices in descending order, which the judge rejects because it expects the smaller index first.

class Solution:
    def twoSum(self, nums, target):
        seen = {}
        for i, v in enumerate(nums):
            complement = target - v
            if complement in seen:
                return [i, seen[complement]]  # order reversed
            seen[v] = i
        return []

You open the custom test case editor and enter the sample from the statement:

Input:
[2,7,11,15]
9
Expected Output:
[0,1]

After clicking "Run Code", the result panel shows:

• Actual output: [1,0]
• Expected output: [0,1]

The mismatch is obvious: the order of the two indices is swapped. You fix the return statement to [seen[complement], i], rerun the same custom test, and now both outputs match.

Expanding the Test Suite

Once the basic case works, add boundary inputs to catch hidden issues:

• Empty array: []\n0 → expected []
• Single element that cannot form a pair: [5]\n10 → expected []
• Maximum constraints (e.g., 10⁵ elements) to gauge performance.

For each case you verify that the actual output matches the manually typed expected output. If a case fails, you have a concrete scenario to inspect with print statements or a debugger.

Performance Checks and Limits

The editor also reports runtime and memory, letting you spot inefficient algorithms. You can paste a large generated input (e.g., a descending list of 10⁵ numbers) and observe whether the solution stays within typical limits. Note that LeetCode may truncate inputs that exceed a certain size, so very large custom tests might not reflect the true worst‑case hidden test.

Trade‑Offs and Limitations

Passing all custom test cases does **not** guarantee acceptance because:

• Hidden tests may include edge cases you never thought to add.
• Manually entered expected output can contain a typo, leading you to chase a non‑existent bug.
• Some problems use a special judge that accepts multiple valid outputs; a single expected value may be misleading.
• Interface labels and availability can change over time.

To mitigate these risks, adopt the following verification steps:

1. Run a few random small inputs through a brute‑force reference implementation and compare outputs automatically.
2. After your custom tests all pass, submit the solution and confirm the judge accepts it.
3. If you suspect a performance issue, generate the largest input allowed by the statement and observe the runtime; if it approaches the limit, consider algorithmic improvements.

Actionable Closing

The custom test case editor is a lightweight, immediate feedback loop that turns vague "Wrong Answer" results into concrete debugging scenarios. Use it to validate sample cases, probe boundaries, and spot performance bottlenecks, but always follow up with an official submission to ensure your solution withstands the hidden test suite. By combining manual case creation with automated random checks, you gain confidence without over‑relying on any single method.