CodeRabbit Generated Unit Tests: Add unit tests#31
Conversation
|
Important Review skippedThis PR was authored by the user configured for CodeRabbit reviews. CodeRabbit does not review PRs authored by this user. It's recommended to use a dedicated user account to post CodeRabbit review feedback. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs |
guardscan-backend | bfc6d7d | Jun 11 2026, 05:26 PM |
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Nitpick comments (4)
cli/__tests__/core/cost-guard.test.ts (1)
186-247: ⚡ Quick winConsider reorganizing scattered test blocks.
The describe blocks for "budget checking – monthly limit" (line 186), "budget checking – zero cost" (line 205), and "budget status – remaining calculation" (line 218) are separated from their logical groups. The first two belong with the "budget checking" tests (lines 13-56), and the third belongs with "budget status" tests (lines 58-91).
📁 Suggested reorganization
Move the monthly limit test (lines 186-203) and zero cost test (lines 205-216) into the "budget checking" describe block:
describe('budget checking', () => { it('should allow requests within budget', async () => { ... }); it('should reject requests exceeding per-request limit', async () => { ... }); it('should reject requests exceeding daily limit', async () => { ... }); + it('should reject requests exceeding monthly limit', async () => { ... }); + it('should allow zero-cost requests', async () => { ... }); });Move the remaining calculation tests (lines 218-247) into the "budget status" describe block:
describe('budget status', () => { it('should provide accurate budget status', async () => { ... }); it('should generate warnings at threshold', async () => { ... }); + it('should not report negative remaining budget', async () => { ... }); + it('should emit daily-limit-reached warning in getBudgetStatus', async () => { ... }); });🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@cli/__tests__/core/cost-guard.test.ts` around lines 186 - 247, The three describe blocks named "budget checking – monthly limit", "budget checking – zero cost", and "budget status – remaining calculation" are placed outside their logical parent groups; move the two "budget checking" describe blocks into the existing "budget checking" suite and move the "budget status – remaining calculation" describe into the existing "budget status" suite so related tests are grouped together; locate the blocks by their exact describe titles and cut/paste each entire describe(...) block into the appropriate parent describe so setup/teardown and naming remain consistent.cli/__tests__/commands/budget.test.ts (1)
70-79: Fragile reliance on Commander’s internal_actionHandler.
callSubcommandActionreaches into Commander’s internals viaawait (sub as any)._actionHandler(options);, which is a private/private-like implementation detail and can break with Commander upgrades.🔄 Alternative approaches
Option 1: Drive the subcommand through Commander’s public parsing flow (e.g.,
parseAsync) instead of invoking_actionHandlerdirectly.async function callSubcommandAction( subcommandName: string, options: Record<string, unknown> = {} ): Promise<void> { const program = createBudgetCommand(); const args = ['node', 'budget', subcommandName]; for (const [key, value] of Object.entries(options)) { args.push(`--${key}`, String(value)); } await program.parseAsync(args); }Option 2: Extract the subcommand’s business logic into separately testable functions, and only integration-test the wiring with Commander.
Option 3: If keeping the current approach, document the fragility clearly (tradeoff: convenience vs upgrade brittleness).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@cli/__tests__/commands/budget.test.ts` around lines 70 - 79, callSubcommandAction currently calls Commander’s private `_actionHandler` on the subcommand (fragile); replace that with driving the command through Commander’s public parsing flow by creating the program with createBudgetCommand(), building an argv array like ['node','budget', subcommandName, ...flags] from the options (convert each key/value to `--key value`) and calling program.parseAsync(argv); alternatively, extract the subcommand business logic into a separate function and call that directly from tests, keeping commander wiring thin (refer to callSubcommandAction, createBudgetCommand, and the subcommand names when locating code to change).cli/__tests__/commands/cache.test.ts (2)
64-64: ⚖️ Poor tradeoffType-safety bypass with 'as any' to access private API.
The code uses
(sub as any)._actionHandlerto invoke a private Commander.js method. While this may be necessary for testing, it bypasses type safety and couples the test to internal implementation details.Consider one of these alternatives:
- If Commander.js exposes a public API for invoking actions in tests, prefer that.
- Document why the private API access is necessary with a comment.
- Extract action logic to testable public functions when feasible.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@cli/__tests__/commands/cache.test.ts` at line 64, The test is calling the private Commander API via (sub as any)._actionHandler which bypasses TypeScript safety and couples tests to internals; replace this by invoking the public action handler or extracting the action logic into a testable function: either call the command's public .action callback through the exported function that implements the command's behavior (extract from where sub is constructed), or add a short comment justifying why using the private _actionHandler is unavoidable; update tests to call the new public function (or documented private access) instead of casting to any.
343-353: ⚖️ Poor tradeoffTesting AICache constructor implementation details.
These tests verify the exact arguments passed to the
AICacheconstructor (default 100 MB vs configured 200 MB). While functional, this approach tests implementation details rather than observable behavior, making tests brittle if the internal instantiation logic changes.Consider whether the behavior (cache clearing with correct capacity) can be verified through side effects or return values instead of constructor argument inspection. However, if constructor argument validation is intentional to ensure correct wiring, this pattern is acceptable.
Also applies to: 355-365
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@cli/__tests__/commands/cache.test.ts` around lines 343 - 353, The test is asserting implementation details by checking the exact arguments passed to the AICache constructor (AICache) via mockLoadOrInit; change the test to assert observable behavior instead: invoke callSubcommandAction('clear', { force: true }) and verify the cache was cleared or that the cache instance reports the expected capacity (e.g., inspect AICache.prototype.clear call, an exposed size/capacity getter, or side effects like files removed) rather than using expect(AICache).toHaveBeenCalledWith(...); update both occurrences (the one around the default 100 MB check and the similar 200 MB check) to assert outcomes or state on the AICache instance or its mock methods (use mockLoadOrInit to return a mocked instance exposing clear/size) instead of constructor-argument inspection.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@cli/__tests__/commands/budget.test.ts`:
- Around line 22-44: The test declares several jest mock functions
(mockGetBudgetStatus, mockGetUsageReport, mockExportUsage, mockClearUsage,
mockRecordUsage, mockCheckBudget) without TypeScript types which causes errors
when calling mockResolvedValue; fix by adding explicit mock types for each (e.g.
use jest.MockedFunction or jest.fn<ReturnType<typeof
CostGuard.prototype.getBudgetStatus>, Parameters<typeof
CostGuard.prototype.getBudgetStatus>>()) or import the actual method return
types from the CostGuard module and use jest.fn<ThatReturnType,
ThatParamTypes>() so calls like mockGetBudgetStatus.mockResolvedValue(...) are
type-safe; update all six mock declarations accordingly.
In `@cli/__tests__/commands/cache.test.ts`:
- Around line 128-129: Tests use map callbacks like
consoleSpy.mock.calls.map((c) => ...) with implicit any; update each occurrence
(e.g., in cache.test.ts where consoleSpy.mock.calls.map is used) to explicitly
type the callback parameter as any[] (for example change (c) to (c: any[])) so
TypeScript strict mode is satisfied, keeping the rest of the mapping logic
(String(c[0])) unchanged and apply this to all listed occurrences.
- Around line 210-211: The map callbacks using the parameter named "c" (e.g. the
expression ".map((c) => (c[0] as string) ?? '')") have implicit any types;
annotate the callback parameter with an explicit tuple/type (for example (c:
[string, unknown]) or (c: [string, string]) depending on the actual entry shape)
so TypeScript knows c[0] is a string, update the same pattern in the other
occurrence(s) in the file, and remove unnecessary casts if the annotation makes
them redundant.
- Line 62: The find callback uses an implicitly typed parameter `c` (in the
expression program.commands.find((c) => ...)) which violates strict TypeScript;
update the callback to use an explicit Commander type (e.g., import type {
Command } from 'commander') and annotate the parameter as that type so the
expression becomes program.commands.find((c: Command) => c.name() ===
subcommandName) and ensure the import of Command is added at the top of the test
file.
In `@cli/__tests__/core/cost-guard.test.ts`:
- Line 89: The arrow callbacks passed to Array.prototype.some in the test (e.g.,
the callback used in expect(status.warnings.some((w) => w.includes('80%'))))
lack explicit types and cause implicit any; add explicit type annotations for
the callback parameter (for example annotate w as string) in this .some callback
and the other occurrence referenced (the one at the later occurrence around line
245) so both callbacks become (w: string) => ... to satisfy TypeScript strict
typing.
- Around line 9-12: The beforeEach creates an unused CostGuard('test-repo') and
calls clearUsage but the instance isn't stored, so remove the entire beforeEach
block to avoid a no-op; alternatively, if you intended to clear usage before
each test, declare a shared const costGuard = new CostGuard('test-repo') (or an
appropriately configured shared instance) in the test scope and call
costGuard.clearUsage() inside beforeEach instead—refer to CostGuard, beforeEach,
and clearUsage to locate the code to remove or update.
In `@cli/__tests__/providers/decorators/rate-limited-provider.test.ts`:
- Around line 6-10: The test import fails because the module
'../../../src/providers/decorators/rate-limited-provider' doesn't exist in this
package; create a source module that exports RateLimitedProvider,
DEFAULT_RATE_LIMIT_CONFIG, and PROVIDER_RATE_LIMITS (matching the named exports
used in the test) — e.g., add a file exporting the RateLimitedProvider
decorator/class and the two constants (DEFAULT_RATE_LIMIT_CONFIG and
PROVIDER_RATE_LIMITS) with the expected shapes/values so the test can import
them successfully.
- Around line 219-227: Type error occurs because
Object.entries(PROVIDER_RATE_LIMITS) yields unknown for cfg; fix by asserting
the entries to a known typed tuple array so cfg is recognized (e.g. change the
loop to: for (const [providerName, cfg] of Object.entries(PROVIDER_RATE_LIMITS)
as [string, ProviderRateLimitConfig][]) { ... } ), or cast PROVIDER_RATE_LIMITS
to Record<string, ProviderRateLimitConfig> before calling Object.entries; ensure
ProviderRateLimitConfig (or similarly named) exists/imported and has maxTokens,
refillRate, costMultiplier so the typeof and range assertions on cfg work
without TS errors (referencing PROVIDER_RATE_LIMITS, cfg, providerName).
- Around line 80-100: The inline comment in the test "should wait when
insufficient tokens" is incorrect about token consumption; update the comment
that currently says "500 tokens / 1000 tokens per second" to reflect that
MockProvider.countMessagesTokens() returns 1000 tokens so each request consumes
1000 tokens (with costMultiplier 1.0), i.e., "1000 tokens / 1000 tokens per
second", or remove the misleading token math; locate the comment near the test
case and references to MockProvider.countMessagesTokens() and
RateLimitedProvider.chat to make the change.
---
Nitpick comments:
In `@cli/__tests__/commands/budget.test.ts`:
- Around line 70-79: callSubcommandAction currently calls Commander’s private
`_actionHandler` on the subcommand (fragile); replace that with driving the
command through Commander’s public parsing flow by creating the program with
createBudgetCommand(), building an argv array like ['node','budget',
subcommandName, ...flags] from the options (convert each key/value to `--key
value`) and calling program.parseAsync(argv); alternatively, extract the
subcommand business logic into a separate function and call that directly from
tests, keeping commander wiring thin (refer to callSubcommandAction,
createBudgetCommand, and the subcommand names when locating code to change).
In `@cli/__tests__/commands/cache.test.ts`:
- Line 64: The test is calling the private Commander API via (sub as
any)._actionHandler which bypasses TypeScript safety and couples tests to
internals; replace this by invoking the public action handler or extracting the
action logic into a testable function: either call the command's public .action
callback through the exported function that implements the command's behavior
(extract from where sub is constructed), or add a short comment justifying why
using the private _actionHandler is unavoidable; update tests to call the new
public function (or documented private access) instead of casting to any.
- Around line 343-353: The test is asserting implementation details by checking
the exact arguments passed to the AICache constructor (AICache) via
mockLoadOrInit; change the test to assert observable behavior instead: invoke
callSubcommandAction('clear', { force: true }) and verify the cache was cleared
or that the cache instance reports the expected capacity (e.g., inspect
AICache.prototype.clear call, an exposed size/capacity getter, or side effects
like files removed) rather than using expect(AICache).toHaveBeenCalledWith(...);
update both occurrences (the one around the default 100 MB check and the similar
200 MB check) to assert outcomes or state on the AICache instance or its mock
methods (use mockLoadOrInit to return a mocked instance exposing clear/size)
instead of constructor-argument inspection.
In `@cli/__tests__/core/cost-guard.test.ts`:
- Around line 186-247: The three describe blocks named "budget checking –
monthly limit", "budget checking – zero cost", and "budget status – remaining
calculation" are placed outside their logical parent groups; move the two
"budget checking" describe blocks into the existing "budget checking" suite and
move the "budget status – remaining calculation" describe into the existing
"budget status" suite so related tests are grouped together; locate the blocks
by their exact describe titles and cut/paste each entire describe(...) block
into the appropriate parent describe so setup/teardown and naming remain
consistent.
🪄 Autofix (Beta)
✅ Autofix completed
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: a8fc24f5-85ac-4237-b533-a62e56ae94d2
📒 Files selected for processing (4)
cli/__tests__/commands/budget.test.tscli/__tests__/commands/cache.test.tscli/__tests__/core/cost-guard.test.tscli/__tests__/providers/decorators/rate-limited-provider.test.ts
| import { | ||
| RateLimitedProvider, | ||
| DEFAULT_RATE_LIMIT_CONFIG, | ||
| PROVIDER_RATE_LIMITS, | ||
| } from '../../../src/providers/decorators/rate-limited-provider'; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify the rate-limited-provider source file exists
# Check if the expected source file exists
fd -t f 'rate-limited-provider\.ts$' cli/src
# If found elsewhere, show its location
fd -t f 'rate-limited-provider' cli/Repository: ntanwir10/GuardScan
Length of output: 128
Fix failing test import (TS2307): missing rate-limited-provider implementation
TS cannot resolve ../../../src/providers/decorators/rate-limited-provider (only cli/__tests__/providers/decorators/rate-limited-provider.test.ts matches; no corresponding source file under cli/src).
🧰 Tools
🪛 GitHub Actions: CI/CD Pipeline / 5_Test CLI (20).txt
[error] 10-10: TypeScript error TS2307: Cannot find module '../../../src/providers/decorators/rate-limited-provider' or its corresponding type declarations.
🪛 GitHub Actions: CI/CD Pipeline / Test CLI (20)
[error] 10-10: TS2307: Cannot find module '../../../src/providers/decorators/rate-limited-provider' or its corresponding type declarations.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@cli/__tests__/providers/decorators/rate-limited-provider.test.ts` around
lines 6 - 10, The test import fails because the module
'../../../src/providers/decorators/rate-limited-provider' doesn't exist in this
package; create a source module that exports RateLimitedProvider,
DEFAULT_RATE_LIMIT_CONFIG, and PROVIDER_RATE_LIMITS (matching the named exports
used in the test) — e.g., add a file exporting the RateLimitedProvider
decorator/class and the two constants (DEFAULT_RATE_LIMIT_CONFIG and
PROVIDER_RATE_LIMITS) with the expected shapes/values so the test can import
them successfully.
|
Note Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. Fixes Applied SuccessfullyFixed 5 file(s) based on 9 unresolved review comments. Files modified:
Commit: The changes have been pushed to the Time taken: |
Fixed 5 file(s) based on 9 unresolved review comments. Co-authored-by: CodeRabbit <noreply@coderabbit.ai>
Unit test generation was requested by @ntanwir10.
The following files were modified:
cli/__tests__/commands/budget.test.tscli/__tests__/commands/cache.test.tscli/__tests__/core/cost-guard.test.tscli/__tests__/providers/decorators/rate-limited-provider.test.tsSummary by CodeRabbit