chore: use expectTypeOf in tests #131
Conversation
📝 WalkthroughSummary by CodeRabbit
WalkthroughTest-only updates across backend and frontend: migrate runtime typeof checks to expectTypeOf assertions, adjust some non-null assertions in store tests, and change Pinia test setup to run actions by disabling stubbing. No production code or public API changes. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~7 minutes Possibly related PRs
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
frontend/src/features/wikibase-schema/stores/__tests__/schema.store.test.ts (1)
16-31: Add missing imports: PropertyValueMap & ReferenceSchemaMappingBoth types are exported from backend/src/api/project/project.wikibase.ts but are not imported in the test file — add them to the existing import.
- backend/src/api/project/project.wikibase.ts — exports PropertyValueMap (line ~80) and ReferenceSchemaMapping (line ~88)
- frontend/src/features/wikibase-schema/stores/tests/schema.store.test.ts — top-level import missing these types
Apply this change in the test:
-import type { - ColumnMapping, - PropertyReference, - ValueMapping, -} from '@backend/api/project/project.wikibase' +import type { + ColumnMapping, + PropertyReference, + ValueMapping, + PropertyValueMap, + ReferenceSchemaMapping, +} from '@backend/api/project/project.wikibase'
🧹 Nitpick comments (2)
frontend/src/shared/composables/__tests__/useDragDropContext.test.ts (2)
270-277: Great switch to type-level assertions for composable method presence; consider adding signature checksYou validated existence via toBeFunction(). Add return/parameter type checks to harden against signature regressions.
Apply the following additions near these assertions:
expectTypeOf(context.startDrag).toBeFunction() expectTypeOf(context.endDrag).toBeFunction() expectTypeOf(context.enterDropZone).toBeFunction() expectTypeOf(context.leaveDropZone).toBeFunction() expectTypeOf(context.validateDrop).toBeFunction() expectTypeOf(context.performDrop).toBeFunction() expectTypeOf(context.createDropZoneConfig).toBeFunction() + // Optional: strengthen with signature checks + expectTypeOf(context.performDrop).returns.toEqualTypeOf<Promise<boolean>>() + expectTypeOf(context.createDropZoneConfig) + .parameters.toEqualTypeOf<[string, WikibaseDataType[], (column: ColumnInfo) => void]>()
292-292: Type-level assertion for getValidTargetsForColumn is good; consider adding return type checkMinor enhancement: add a compile-time return type check for clarity.
You can add:
const store = useDragDropStore() - expectTypeOf(store.getValidTargetsForColumn).toBeFunction() + expectTypeOf(store.getValidTargetsForColumn).toBeFunction() + expectTypeOf(store.getValidTargetsForColumn) + .returns.toEqualTypeOf<DropTarget[]>() + expectTypeOf(store.getValidTargetsForColumn) + .parameters.toEqualTypeOf<[ColumnInfo]>()
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these settings in your CodeRabbit configuration.
📒 Files selected for processing (4)
backend/tests/db.test.ts(4 hunks)frontend/src/features/wikibase-schema/composables/__tests__/useSchemaApi.test.ts(1 hunks)frontend/src/features/wikibase-schema/stores/__tests__/schema.store.test.ts(4 hunks)frontend/src/shared/composables/__tests__/useDragDropContext.test.ts(3 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit Inference Engine (.cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc)
**/*.{ts,tsx,js,jsx}: Usebun <file>instead ofnode <file>orts-node <file>for running TypeScript or JavaScript files
Do not use dotenv; Bun automatically loads .env files
UseBun.serve()for HTTP servers and WebSockets instead ofexpress
Usebun:sqlitefor SQLite instead ofbetter-sqlite3
UseBun.redisfor Redis instead ofioredis
UseBun.sqlfor Postgres instead ofpgorpostgres.js
Use built-inWebSocketinstead ofws
PreferBun.fileovernode:fs's readFile/writeFile
UseBun.$(e.g.,Bun.$ls``) instead of execa for running shell commands
Files:
frontend/src/features/wikibase-schema/composables/__tests__/useSchemaApi.test.tsfrontend/src/features/wikibase-schema/stores/__tests__/schema.store.test.tsfrontend/src/shared/composables/__tests__/useDragDropContext.test.tsbackend/tests/db.test.ts
**/*.test.{ts,tsx,js,jsx}
📄 CodeRabbit Inference Engine (.cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc)
Use
bun testinstead ofjestfor running tests
Files:
frontend/src/features/wikibase-schema/composables/__tests__/useSchemaApi.test.tsfrontend/src/features/wikibase-schema/stores/__tests__/schema.store.test.tsfrontend/src/shared/composables/__tests__/useDragDropContext.test.tsbackend/tests/db.test.ts
**/*.{html,ts,tsx,css}
📄 CodeRabbit Inference Engine (.cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc)
Use
bun build <file.html|file.ts|file.css>instead ofwebpackoresbuildfor building HTML, TypeScript, or CSS files
Files:
frontend/src/features/wikibase-schema/composables/__tests__/useSchemaApi.test.tsfrontend/src/features/wikibase-schema/stores/__tests__/schema.store.test.tsfrontend/src/shared/composables/__tests__/useDragDropContext.test.tsbackend/tests/db.test.ts
🧠 Learnings (3)
📚 Learning: 2025-07-20T14:13:24.706Z
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/frontend-setup.rule.md:0-0
Timestamp: 2025-07-20T14:13:24.706Z
Learning: Applies to src/composables/**/*.ts : Do not proxy or export Pinia store state/actions from composables
Applied to files:
frontend/src/features/wikibase-schema/composables/__tests__/useSchemaApi.test.ts
📚 Learning: 2025-07-20T14:13:40.153Z
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.153Z
Learning: Applies to **/*.test.{ts,tsx,js,jsx} : Use `bun test` instead of `jest` for running tests
Applied to files:
frontend/src/features/wikibase-schema/stores/__tests__/schema.store.test.tsfrontend/src/shared/composables/__tests__/useDragDropContext.test.tsbackend/tests/db.test.ts
📚 Learning: 2025-07-20T14:13:40.153Z
Learnt from: CR
PR: DaxServer/dataforge#0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-07-20T14:13:40.153Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use `bun:sqlite` for SQLite instead of `better-sqlite3`
Applied to files:
backend/tests/db.test.ts
🔇 Additional comments (9)
frontend/src/features/wikibase-schema/composables/__tests__/useSchemaApi.test.ts (1)
95-99: Enabling real Pinia actions in tests is appropriate hereSwitching stubActions to false makes the tests verify actual state transitions, which matches the assertions below (e.g., schemaId, projectId updates). The createSpy: mock still spies on actions, so call assertions remain valid. Good alignment with the PR’s intent.
frontend/src/shared/composables/__tests__/useDragDropContext.test.ts (2)
1-1: Adopting expectTypeOf for type-level assertions is consistent with the PR objectiveImporting expectTypeOf from bun:test prepares this test to assert API surface types without runtime checks. Good move.
281-281: Type-level assertion for setAvailableTargets looks goodMatches the store API described in drag-drop.store. No concerns.
backend/tests/db.test.ts (1)
1-1: Type-level checks for db.run are aligned with PR; LGTMUsing expectTypeOf(db.run).toBeFunction() removes unnecessary runtime typeof checks while preserving intent. No further issues spotted.
Also applies to: 13-13, 25-25, 68-68
frontend/src/features/wikibase-schema/stores/__tests__/schema.store.test.ts (5)
1-1: Adopting expectTypeOf import is on pointConsistent with the broader migration to type-level assertions.
56-61: Running real store actions in tests is appropriatestubActions: false ensures state changes are exercised, which your tests rely on. With createSpy: mock, action calls remain observable. Well set.
637-638: Type-level assertion for statement id is a good replacementClearer than runtime checks; helps catch regressions at compile-time.
655-656: Type-level assertion for property object looks goodKeeps the test focused on structure without runtime coupling.
673-674: Type-level assertion for value object looks goodMatches the intended shape of the statement value mapping.
1 participant
No description provided.