Why My LeetCode Solution Passes Some Test Cases But Fails Others

Source: Dev.to

TL;DR

• Partial pass usually means edge cases or boundary conditions. Your core logic is likely correct, but fails on specific inputs.
• The most common culprits: empty inputs, single elements, maximum/minimum values, duplicates, and off‑by‑one indexing errors.
• Systematic debugging trumps guessing. Generate test cases methodically instead of randomly hoping to find the bug.
• Look at which test cases pass vs. fail. Early passes with late failures often indicate constraint‑related issues or extreme values.
• The bug is usually simpler than you think. Most partial failures come from overlooked edge cases, not fundamental algorithm flaws.

Beginner‑Friendly Explanations

Why Partial Failures Happen

When code passes some tests but fails others, it typically means:

• Your algorithm is mostly correct — you understood the problem and implemented a valid approach.
• Your implementation misses specific cases — certain inputs expose gaps in your logic.

This is actually better than getting zero passes. A complete failure suggests a fundamental misunderstanding; partial failure suggests you’re close but missing something.

The Hidden Test Case Challenge

LeetCode’s hidden test cases are designed to catch:

• Edge cases: empty arrays, single elements, maximum size inputs.
• Boundary values: smallest/largest numbers allowed by constraints.
• Special patterns: all duplicates, all same value, sorted/reverse‑sorted.
• Performance limits: inputs at the maximum constraint size.

Understanding what LeetCode tests for helps you anticipate what might break.

Step‑by‑Step Learning Guidance

Step 1: Analyze the Failure Pattern

Before debugging, gather information:

• How many tests passed vs. failed? (e.g., “47/53 passed”)
• What type of failure? (Wrong Answer, Time Limit Exceeded, Runtime Error)
• Does LeetCode show the failing input? (Sometimes it does for Wrong Answer)

Pattern interpretation

Step 2: Generate Edge‑Case Test Inputs

Systematically create inputs that stress your solution. Here’s a checklist.

For Array Problems

// Empty array
[]
// Single element
[1]
// Minimum interesting size
[1, 2]
// All duplicates
[1, 1, 1, 1]
// Sorted ascending
[1, 2, 3, /* … */ , n]
// Sorted descending
[n, n-1, /* … */ , 1]
// Constraint boundaries
[max_val, min_val]

For String Problems

""                     // Empty string
"a"                    // Single character
"aaaa"                 // All same character
"constraint_max_len"  // Maximum length string

For Number Problems

0          // Zero
1          // One
-1         // Negative one
MAX_INT    // Maximum integer value
MIN_INT    // Minimum integer value

Test each of these against your solution before submitting.

Step 3: Look for Off‑by‑One Errors

Off‑by‑one errors are the most common cause of partial failures. Check every loop and index access:

// Common off‑by‑one patterns to audit

// Loop boundaries
for (let i = 0; i < arr.length; i++)     // Correct for full array
for (let i = 0; i <= arr.length; i++)    // ERROR: accesses arr[length]
for (let i = 1; i < arr.length; i++)     // Misses first element
for (let i = 0; i < arr.length - 1; i++) // Misses last element

// Array access
arr[i - 1]  // Fails when i = 0
arr[i + 1]  // Fails when i = length - 1

// Substring/slice
str.slice(0, n)    // Characters 0 to n‑1 (n not included)
str.substring(0, n) // Same as slice

Step 4: Check Constraint Boundaries

Read the problem constraints carefully. Then verify your code handles:

• Size constraints: n = 0, n = 1, n = max_constraint.
• Value constraints: negative values, zeros, potential integer overflow.

Example: If the constraint says “1 ≤ n ≤ 10⁵” and values can be up to 10⁹, then sum = values[i] + values[j] could overflow a 32‑bit integer.

Step 5: Trace Through a Failing Input

When you find (or suspect) a failing input, manually trace your code:

1. Write down initial variable values.
2. Step through each line, updating values.
3. Compare your trace to expected behavior.
4. Identify where the first deviation occurs.

This relates to the manual code tracing technique essential for debugging.

Step 6: Add Targeted Print Statements

If manual tracing doesn’t reveal the bug, add print statements at critical points:

function solve(nums) {
    console.log("Input:", nums);

    for (let i = 0; i < nums.length; i++) {
        // ... logic
        console.log(`After i=${i}: state=`, state);
    }

    console.log("Final result:", result);
    return result;
}

Run with your edge cases and compare the trace to your expectations.

Common Causes and Fixes

Cause 1: Empty Input Not Handled

Symptom: Passes all tests except those with empty arrays or strings.

Bug example:

function findMax(nums) {
    let max = nums[0];  // ERROR: crashes if nums is empty
    // ...
}

Fix:

function findMax(nums) {
    if (nums.length === 0) return -Infinity; // or appropriate default
    let max = nums[0];
    // ...
}

Cause 2: Single Element Edge Case

Symptom: Works for arrays of length 2+, fails for length 1.

Bug example:

function twoSum(nums, target) {
    for (let i = 0; i < nums.length; i++) {
        for (let j = i + 1; j < nums.length; j++) {
            // With length 1, inner loop never executes
        }
    }
    return [];  // Returns empty for single‑element input
}

Check whether a single‑element input is valid for the problem and handle it accordingly.

Cause 3: Off‑by‑One in Loop Bounds

Symptom: Missing the first or last element, or accessing out‑of‑range indices.

Bug example:

for (let i = 0; i <= arr.length; i++) { // accesses arr[arr.length] → undefined
    // ...
}

Fix:

for (let i = 0; i < arr.length; i++) { // correct bounds
    // ...
}

Cause 4: Ignoring Value Constraints

Symptom: Incorrect results or overflow when values hit extreme limits.

Bug example:

let product = a * b; // May overflow 32‑bit integer

Fix: Use larger numeric types (e.g., BigInt in JavaScript) or apply modular arithmetic if the problem specifies it.

Cause 5: Time Complexity Too High

Symptom: Passes small test cases, fails larger hidden ones with Time Limit Exceeded.

Typical fix: Replace O(n²) loops with O(n log n) or O(n) approaches, use hash maps, two‑pointer techniques, or efficient data structures.

---

By following this systematic approach—analyzing patterns, generating edge cases, checking off‑by‑one errors, respecting constraints, tracing manually, and using targeted debugging output—you can turn partial passes into full passes and master LeetCode’s hidden test challenges.