Skip to content

🧪 [Testing] Add robust test suite for utils/handleError.js#58

Open
zknpr wants to merge 1 commit intomainfrom
add-tests-handleError-6414772691796114345
Open

🧪 [Testing] Add robust test suite for utils/handleError.js#58
zknpr wants to merge 1 commit intomainfrom
add-tests-handleError-6414772691796114345

Conversation

@zknpr
Copy link
Copy Markdown
Owner

@zknpr zknpr commented Mar 8, 2026

🎯 What: Implemented missing test coverage for the handleError utility in utils/handleError.js.
📊 Coverage: Mocked console.log, console.error, and process.exit correctly. Test cases cover happy path error strings, parsing and processing of GraphQL errors (with and without explicitly stated chains), Axios error handling, and correct mapping and truncation of error stacks.
Result: Enhanced test coverage ensures stability and predictable outcomes when dealing with formatted application panics in adapters.


PR created automatically by Jules for task 6414772691796114345 started by @zknpr

Co-authored-by: zknpr <96851588+zknpr@users.noreply.github.com>
@google-labs-jules
Copy link
Copy Markdown

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.


For security, I will only act on instructions from the user who triggered this task.

@gemini-code-assist
Copy link
Copy Markdown

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Mar 8, 2026

Warning

Rate limit exceeded

@zknpr has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 18 minutes and 17 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 0562238f-6003-4052-9af5-37e62fdd3998

📥 Commits

Reviewing files that changed from the base of the PR and between 0d3be2a and 9c1025c.

📒 Files selected for processing (1)
  • utils/__tests__/handleError.test.js
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch add-tests-handleError-6414772691796114345

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@greptile-apps
Copy link
Copy Markdown

greptile-apps bot commented Mar 8, 2026

Greptile Summary

This PR adds a new test file (utils/__tests__/handleError.test.js) that provides coverage for the handleError utility using Node.js's built-in node:test runner. It exercises the happy path, GraphQL error formatting (with and without a chain), Axios error logging, checkExportKeys short-circuit, stack filtering, and the empty-stack edge case.

Key observations:

  • Coverage gap — undefined in truncated stack output: The "Standard error handling" test does not assert on the truncated-stack log content. Due to a bug in handleError.js (message.push(firstNMStackMessage, ...stack) where firstNMStackMessage can be undefined), the literal string "undefined" is prepended to the printed stack trace whenever no node_modules frame is present. None of the tests surface this, so the bug goes undetected.
  • Fragile stack-content lookup in the "standard filtering" subtest: The test retrieves logMessages[stackLogIndex + 1] without first asserting that the entry exists. If the message is absent, .includes() will throw a TypeError rather than producing a clear assertion failure.
  • Mocking strategy (console.log, console.error, process.exit) and use of t.beforeEach/t.afterEach for cleanup are implemented correctly.
  • All other assertions are logically sound and match the implementation's actual behaviour.

Confidence Score: 3/5

  • Safe to merge with minor caveats — the tests pass but leave a real source-code bug uncovered.
  • The test suite is well-structured and all assertions against the implementation are correct. However, a coverage gap in the "Standard error handling" subtest means an existing bug (printing the literal string "undefined" in truncated stack output) goes undetected, reducing confidence in the suite's ability to catch regressions. The fragile index-based lookup in the filtering test is a secondary concern.
  • utils/tests/handleError.test.js — specifically the "Standard error handling" subtest (lines 42–51) and the stack-content lookup in the "standard filtering" subtest (lines 133–139).

Important Files Changed

Filename Overview
utils/tests/handleError.test.js New test suite covering the handleError utility. All tests are expected to pass, but there is a coverage gap: the "Standard error handling" case does not assert on truncated-stack output, which allows an existing source-code bug (undefined printed to the stack) to go undetected. Additionally, the stack-content lookup in the "standard filtering" test lacks a guard before calling .includes() on the retrieved value.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[handleError called] --> B[console.log header]
    B --> C{isGraphError?\nstack includes 'graphql-request'\n&& response.errors exists}
    C -- Yes --> D[console.error GraphQL errors\nwith chain or 'Unknown']
    C -- No --> E[console.error error.toString]
    D --> F{axiosError?\nresponse.data.message exists}
    E --> F
    F -- Yes --> G[console.log Axios message]
    F -- No --> H[getStackMessage]
    G --> H
    H --> I{stack is null?}
    I -- Yes --> J[return empty array]
    I -- No --> K{checkExportKeys\nin stack?}
    K -- Yes --> J
    K -- No --> L[filter node_modules\nfirstNMStackMessage\nmay be undefined]
    L --> M{message.length > 0?}
    M -- Yes --> N[console.log Truncated stack\nnote: may include 'undefined']
    M -- No --> O[skip stack log]
    N --> P[process.exit 1]
    O --> P
Loading

Last reviewed commit: 9c1025c

Comment on lines +42 to +51
await t.test('Standard error handling', () => {
const error = new Error('Test standard error');
error.stack = 'Error: Test standard error\n at Object.<anonymous> (/test/file.js:1:1)\n at Module._compile (node:internal/modules/cjs/loader:1:1)';

handleError(error);

assert.strictEqual(exitCode, 1, 'process.exit should be called with 1');
assert.ok(logMessages[0].includes('------ ERROR ------'), 'Should log error string');
assert.strictEqual(errorMessages[0], 'Error: Test standard error', 'Should log error.toString()');
});
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test misses source-code bug: undefined in truncated stack output

The "Standard error handling" test does not assert anything about the truncated stack content, which lets a real bug in getStackMessage go undetected.

The bug: When no node-module frame is found in the stack, firstNMStackMessage is undefined. Line 36 of handleError.js then does message.push(firstNMStackMessage, ...stack), placing undefined at index 0. Calling stack.join('\n') on that array produces "undefined\n at Object.<anonymous> ..." — the literal string "undefined" is printed to the console.

Trace for this test's input stack (/test/file.js has no node_modules):

  1. firstNMStackMessageundefined (no node-module frames exist)
  2. message = [undefined, ' at Object.<anonymous>...'] (length 2, so the truncated-stack branch is entered)
  3. console.log(stack.join('\n'))'undefined\n at Object.<anonymous>...'

The test passes today only because no assertion covers the stack output. Adding a check would expose the issue:

Suggested change
await t.test('Standard error handling', () => {
const error = new Error('Test standard error');
error.stack = 'Error: Test standard error\n at Object.<anonymous> (/test/file.js:1:1)\n at Module._compile (node:internal/modules/cjs/loader:1:1)';
handleError(error);
assert.strictEqual(exitCode, 1, 'process.exit should be called with 1');
assert.ok(logMessages[0].includes('------ ERROR ------'), 'Should log error string');
assert.strictEqual(errorMessages[0], 'Error: Test standard error', 'Should log error.toString()');
});
await t.test('Standard error handling', () => {
const error = new Error('Test standard error');
error.stack = 'Error: Test standard error\n at Object.<anonymous> (/test/file.js:1:1)\n at Module._compile (node:internal/modules/cjs/loader:1:1)';
handleError(error);
assert.strictEqual(exitCode, 1, 'process.exit should be called with 1');
assert.ok(logMessages[0].includes('------ ERROR ------'), 'Should log error string');
assert.strictEqual(errorMessages[0], 'Error: Test standard error', 'Should log error.toString()');
// Verify truncated stack does not contain the literal string 'undefined'
const truncatedIdx = logMessages.findIndex(msg => msg.includes('Truncated error stack:'));
if (truncatedIdx !== -1) {
assert.ok(!logMessages[truncatedIdx + 1].startsWith('undefined'), 'Stack output should not start with "undefined"');
}
});

Comment on lines +133 to +139
const stackLogIndex = logMessages.findIndex(msg => msg.includes('Truncated error stack:')) + 1;
const truncatedStack = logMessages[stackLogIndex];

// First element should be the node_modules stack line
assert.ok(truncatedStack.includes('node_modules/axios'));
// internal/modules should be filtered out
assert.ok(!truncatedStack.includes('node:internal'));
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Guard missing before calling .includes() on potentially undefined value

logMessages[stackLogIndex] is used without first verifying it exists. If the findIndex call returns -1 (message not found) or if there is no message immediately after the "Truncated error stack:" entry, truncatedStack will be undefined, and the subsequent .includes() calls will throw a TypeError — hiding the real test failure with a confusing crash message.

Suggested change
const stackLogIndex = logMessages.findIndex(msg => msg.includes('Truncated error stack:')) + 1;
const truncatedStack = logMessages[stackLogIndex];
// First element should be the node_modules stack line
assert.ok(truncatedStack.includes('node_modules/axios'));
// internal/modules should be filtered out
assert.ok(!truncatedStack.includes('node:internal'));
const stackIdx = logMessages.findIndex(msg => msg.includes('Truncated error stack:'));
assert.ok(stackIdx !== -1, '"Truncated error stack:" label should be logged');
const truncatedStack = logMessages[stackIdx + 1];
assert.ok(truncatedStack !== undefined, 'Stack content log message should follow the label');
// First element should be the node_modules stack line
assert.ok(truncatedStack.includes('node_modules/axios'));
// internal/modules should be filtered out
assert.ok(!truncatedStack.includes('node:internal'));

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant