Code Review — Add more unit tests and component tests

Summary: Good coverage addition across analytics, compute, database, functions, realtime, storage, and core utils. The vitest config refactor (splitting environment per config type) is a clean improvement. No blocking issues found.

Requirements context

No spec or plan under /docs/superpowers/ matches this PR's scope (pure test coverage improvement with a config refactor). Assessed against the PR description alone: add unit/component tests across the dashboard and align vitest environments per config type.

Findings

Critical

(none)

Suggestion

[Software Engineering] vitest.config.ts still runs unit .ts tests under jsdom

packages/dashboard/vitest.config.ts:9

The default config includes src/**/*.test.{ts,tsx} with environment: 'jsdom'. This is a superset of both the unit config (.ts → node) and the component config (.tsx → jsdom). As a result, running vitest without an explicit --config flag still executes all unit tests (.ts) in jsdom rather than node. The environment improvement only applies when callers explicitly use vitest.unit.config.ts. Consider noting this in the PR or a follow-up comment/script, or accepting the default config as a "run-everything-in-jsdom" convenience while specialized configs enforce stricter environments in CI.

[Functionality] BucketFormDialog.test.tsx — only create mode tested

packages/dashboard/src/features/storage/components/__tests__/BucketFormDialog.test.tsx:26–47

The mock exposes editBucket but no test exercises the edit mode. A follow-up test would verify that submitting in edit mode calls editBucket (not createBucket) with the updated name.

[Functionality] ChannelFormDialog.test.tsx — only happy-path create tested

packages/dashboard/src/features/realtime/components/__tests__/ChannelFormDialog.test.tsx:7–25

No coverage for: submitting with an empty/invalid pattern (validation rejection), or the edit flow if the component supports it. These would be valuable to add alongside the existing test.

[Functionality] DeleteServiceDialog.test.tsx — error path not covered

packages/dashboard/src/features/compute/components/__tests__/DeleteServiceDialog.test.tsx:7–33

The test exercises the full success path. Worth adding a case where onConfirm rejects — verify the dialog stays open and an error state (if any) is displayed, so that regression protection exists if error handling is changed later.

Information

[Software Engineering] Prefer jest-dom matchers for disabled assertions

packages/dashboard/src/features/compute/components/__tests__/DeleteServiceDialog.test.tsx:21,24
packages/dashboard/src/features/storage/components/__tests__/S3AccessKeyCreateDialog.test.tsx:47,51

// current
expect((deleteButton as HTMLButtonElement).disabled).toBe(true);

// preferred — setup.ts already imports @testing-library/jest-dom/vitest
expect(deleteButton).toBeDisabled();
expect(doneButton).not.toBeDisabled();

toBeDisabled() gives a clearer failure message and avoids the as HTMLButtonElement cast.

[Software Engineering] Redundant .toBeTruthy() on getBy* queries

packages/dashboard/src/features/storage/components/__tests__/S3AccessKeyCreateDialog.test.tsx:41–42

expect(screen.getByText('S3 Access Key Created')).toBeTruthy();
expect(screen.getByDisplayValue(createdKey.accessKeyId)).toBeTruthy();

getBy* queries throw if the element is not found, so .toBeTruthy() is redundant. Prefer toBeInTheDocument() from jest-dom (already available via setup.ts) for a more descriptive failure message, or omit the expect wrapper entirely and rely on the query throw.

Verdict

approved (informational — no Critical findings; a human must give the explicit GitHub approval)

Actionable comments posted: 1

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 `@packages/dashboard/vitest.config.ts`:
- Around line 9-11: The root vitest config currently sets environment: 'jsdom'
and include: ['src/**/*.test.{ts,tsx}'] (with setupFiles) which causes unit and
component tests to run in jsdom; update this file to stop mixing environments by
either removing the test configuration entirely so vitest.unit.config.ts and
vitest.component.config.ts are used exclusively, or change the include pattern
to only component tests (e.g., include only *.test.tsx) and keep environment:
'jsdom' and setupFiles only for component runs; locate the keys environment,
include and setupFiles in vitest.config.ts to apply the change.

---

Nitpick comments:
In
`@packages/dashboard/src/features/realtime/components/__tests__/ChannelFormDialog.test.tsx`:
- Around line 17-24: The test should also assert the dialog is closed by
verifying onOpenChange(false) is called; add a jest mock for onOpenChange (e.g.,
const onOpenChange = jest.fn()) and pass it into the rendered ChannelFormDialog
in the test, then extend the existing waitFor block that checks onCreate to also
expect(onOpenChange).toHaveBeenCalledWith(false). Ensure you place the
onOpenChange mock alongside the existing onCreate mock so the test verifies both
channel creation (onCreate) and dialog closing (onOpenChange(false)).

In `@packages/dashboard/src/lib/utils/__tests__/utils.test.ts`:
- Around line 37-42: The test for formatTime only checks the date portion;
update the assertion for formatTime('2026-05-17T12:30:00.000Z') to also verify
the time component is present (e.g. assert the output contains "12:30" or
matches a time regex like /,\s*\d{1,2}:\d{2}/ or a locale time pattern) while
keeping the invalid-input check unchanged; locate the test in the
describe('formatTime') block and modify the expect for formatTime accordingly.

1 issue found across 14 files

Confidence score: 4/5

• This PR looks safe to merge overall, with only a minor-to-moderate risk centered on test reliability rather than production behavior.
• The main issue is in packages/dashboard/src/lib/utils/__tests__/utils.test.ts: formatting a ...Z timestamp in local time can shift the calendar day, which may cause flaky failures across different timezones/CI environments.
• Given the 4/10 severity and the issue being test-only, risk to end users appears limited, but merge confidence is slightly reduced due to potential intermittent CI instability.
• Pay close attention to packages/dashboard/src/lib/utils/__tests__/utils.test.ts - timezone-dependent date expectations may fail unpredictably across environments.

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/dashboard/src/lib/utils/__tests__/utils.test.ts">

<violation number="1" location="packages/dashboard/src/lib/utils/__tests__/utils.test.ts:39">
P2: This test is timezone-dependent: a `...Z` timestamp formatted in local time can produce a different calendar day, causing flaky failures across environments.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
Re-trigger cubic}

Summary

Solid test-coverage expansion across analytics, database, storage, compute, realtime, and @insforge/ui primitives, with a well-executed vitest config split into node/jsdom project environments.

Requirements context

No matching spec/plan found under /docs/superpowers/ — this is a standalone test-addition initiative. Assessment is against the PR description and the implicit requirement of "increase coverage without breaking existing behaviour."

Findings

Critical

(none)

Suggestion

Software engineering — missing edit-mode coverage for ChannelFormDialog
packages/dashboard/src/features/realtime/components/__tests__/ChannelFormDialog.test.tsx:1-26

The component accepts both mode="create" and mode="edit". In edit mode the form is pre-populated from the channel prop, the submit button label changes to "Save Channel", and the callback interface is different (onEdit vs onCreate). Only create mode is tested. The edit path has distinct logic (diff webhook comparison at ChannelFormDialog.tsx:133-139) that would benefit from at least one test.

Software engineering — @insforge/ui vitest configs have no shared base
packages/ui/vitest.component.config.ts, packages/ui/vitest.unit.config.ts

Unlike the dashboard package (which uses mergeConfig(sharedConfig, ...) to share path aliases and other settings), the UI configs are fully standalone. Right now this is fine because tests only use relative imports. But if path aliases or global test options are ever needed, both files must be updated independently with no shared source. Consider extracting a vitest.shared.config.ts following the dashboard's pattern to avoid future divergence.

Information

Software engineering — direct .disabled property access instead of jest-dom matchers
packages/dashboard/src/features/compute/components/__tests__/DeleteServiceDialog.test.tsx:21, packages/dashboard/src/features/storage/components/__tests__/S3AccessKeyCreateDialog.test.tsx:45

// current
expect((deleteButton as HTMLButtonElement).disabled).toBe(true);

// clearer with @testing-library/jest-dom
expect(deleteButton).toBeDisabled();

@testing-library/jest-dom is a common companion library that provides DOM-aware matchers with better failure messages. If the project chooses to add it, a one-line import in each setup file covers all tests. Not a blocker — the current assertions are functionally correct.

Software engineering — BucketFormDialog and S3AccessKeyCreateDialog cover only the happy path
packages/dashboard/src/features/storage/components/__tests__/BucketFormDialog.test.tsx, packages/dashboard/src/features/storage/components/__tests__/S3AccessKeyCreateDialog.test.tsx

Edit mode for BucketFormDialog and error/rejection paths for both dialogs are not covered. Fine for a first-pass PR; just noting so follow-up work is tracked.

Software engineering — @insforge/ui gets its own hoisted [email protected] install
packages/ui/package.json:78-85, package-lock.json

The lock file shows a nested packages/ui/node_modules/vitest block. If the workspace root already provides the same version of vitest to all packages, the package-level devDependency is redundant. Minor install-time overhead only; no functional issue.

Verdict

approved (informational — no Critical findings; explicit GitHub approval via the approve flow)

LGTM, approved.