Groups tests #3036
Groups tests #3036
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
WalkthroughRemoves two exported type declarations from Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Test as Integration Test
participant Harness as IntegrationHarness
participant API as Groups API
participant DB as Database
Note over Test,Harness: Create group
Test->>Harness: POST /groups (create)
Harness->>API: forward request
API->>DB: insert group
DB-->>API: created record
API-->>Harness: 201 + group
Harness-->>Test: assert created shape
Note over Test,Harness: Read and update
Test->>Harness: GET /groups/{id}
Harness->>API: fetch group
API->>DB: query by id
DB-->>API: record
API-->>Harness: 200 + group
Harness-->>Test: assert matches
Test->>Harness: PATCH /groups/{id}
Harness->>API: update fields
API->>DB: update record
DB-->>API: updated record
API-->>Harness: 200 + merged group
Harness-->>Test: assert merged values
Note over Test,Harness: List and delete
Test->>Harness: GET /groups
Harness->>API: list groups
API->>DB: query list
DB-->>API: group array
API-->>Harness: 200 + array
Harness-->>Test: assert presence
Test->>Harness: DELETE /groups/{id}
Harness->>API: delete
API->>DB: remove record
DB-->>API: ack
API-->>Harness: 200
Harness-->>Test: assert 200, then GET returns 404
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
apps/web/tests/partner-groups/index.test.ts (2)
143-158: LGTM!The deletion test properly validates both the deletion response and confirms the group is no longer accessible with a 404 status. This is good practice for verifying deletion.
Consider adding a
deleteGroupmethod toIntegrationHarnessfor consistency with other resource cleanup methods (deleteLink,deleteTag, etc.). This would help with cleanup if tests fail before reaching the DELETE test.
161-162: TODO: Additional test cases needed.The TODO indicates future tests for default link creation and group move functionality.
Would you like me to help generate these additional test cases or open an issue to track this work?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
apps/web/lib/types.ts(0 hunks)apps/web/tests/partner-groups/index.test.ts(1 hunks)
💤 Files with no reviewable changes (1)
- apps/web/lib/types.ts
🧰 Additional context used
🧬 Code graph analysis (1)
apps/web/tests/partner-groups/index.test.ts (3)
apps/web/lib/types.ts (3)
GroupProps(560-560)GroupWithProgramProps(564-564)GroupExtendedProps(566-566)apps/web/tests/utils/integration.ts (1)
IntegrationHarness(14-118)apps/web/lib/zod/schemas/groups.ts (1)
GroupSchema(51-64)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (7)
apps/web/tests/partner-groups/index.test.ts (7)
14-26: LGTM!The expected group structure properly uses
expect.any()matchers for dynamic fields and sets appropriate defaults that align with the GroupSchema.
28-32: LGTM!Using
.sequentialis appropriate for these integration tests since they have dependencies. The harness initialization and shared group variable are set up correctly.
34-56: LGTM!The group creation test properly generates random data, validates the 201 status, schema conformance, and response structure. Storing the created group for subsequent tests is the right approach.
58-77: LGTM!The test correctly fetches the group, destructures to remove program-specific fields, and validates that the core group data matches with the addition of
utmTemplate: null.
79-111: Good test coverage for group updates.Aside from the bug on line 81, the test properly validates updating multiple group properties including complex structures like
additionalLinks. The validation logic and state update are correct.
113-141: LGTM!The test properly validates the list endpoint, verifies array structure, and comprehensively checks the created group's extended properties. Expecting zero values for metrics on a newly created group is appropriate.
2-6: Verify whether PR removes the imported type definitions.The three imported types (
GroupExtendedProps,GroupProps,GroupWithProgramProps) currently exist and are actively used throughout this test file (lines 14, 32, 43, 59, 99, 114). However, because the PR diff cannot be retrieved, I cannot verify whether your changes actually remove these type exports.Ensure that if your PR modifies
apps/web/lib/types.ts, these types remain exported or are replaced with equivalent definitions that this test can import.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
apps/web/tests/partner-groups/index.test.ts (1)
161-162: TODO tracked for future enhancements.Good practice documenting the planned test cases for default link creation and group move operations.
Would you like me to open a tracking issue for these additional test cases, or help outline the test structure for these scenarios?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/web/tests/partner-groups/index.test.ts(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
apps/web/tests/partner-groups/index.test.ts (3)
apps/web/lib/types.ts (3)
GroupProps(560-560)GroupWithProgramProps(564-564)GroupExtendedProps(566-566)apps/web/tests/utils/integration.ts (1)
IntegrationHarness(14-118)apps/web/lib/zod/schemas/groups.ts (1)
GroupSchema(51-64)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (8)
apps/web/tests/partner-groups/index.test.ts (8)
14-26: LGTM! Well-structured assertion template.The expectedGroup definition provides a clean, reusable assertion pattern for verifying group properties across tests.
28-32: LGTM! Appropriate setup for sequential integration tests.The use of
describe.sequentialand shared state via thegroupvariable is a standard pattern for CRUD integration tests where each operation depends on the previous one.
34-56: LGTM! Comprehensive group creation test.The test properly validates the POST endpoint with schema validation, status code verification, and data shape assertions. The created group is correctly stored for use in subsequent tests.
58-77: LGTM! Proper handling of extended type response.The test correctly destructures program-related fields from the
GroupWithProgramPropsresponse and validates that the base group properties match the created group, including the server-setutmTemplate: null.
79-111: LGTM! Comprehensive update test with previous issue resolved.The test thoroughly validates the PATCH endpoint by updating multiple field types (string, number, enum, array of objects). The previous issue with missing parentheses on
generateRandomName()at line 81 has been correctly fixed.
113-141: LGTM! Thorough validation of list endpoint with extended properties.The test properly validates the GET /groups endpoint and comprehensively checks the extended properties (analytics fields) that are correctly initialized to 0 for a newly created group.
143-158: LGTM! Excellent deletion verification.The test properly validates both the successful deletion response and confirms the resource is truly deleted by expecting a 404 on the subsequent GET request. This is a best practice for delete operation testing.
2-6: The concern raised in the original review comment is not valid. All three imported types are confirmed to be properly exported fromapps/web/lib/types.ts:
GroupProps(line 560)GroupWithProgramProps(line 564)GroupExtendedProps(line 566)The import statement in the test file is correct and will compile without issues.
Likely an incorrect or invalid review comment.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
apps/web/ui/modals/delete-group-modal.tsx (1)
101-101: Improved confirmation clarity with a minor UX consideration.The change from "Delete group" to "confirm delete group" makes the confirmation more explicit and reduces ambiguity. The pattern and display text are consistent.
However, note that the modal title (line 44) and submit button text (line 134) still say "Delete group", while users must type "confirm delete group". Although the instructions clearly state what to type, users might instinctively try typing "Delete group" based on what they see elsewhere in the modal.
Consider standardizing the confirmation phrase across all text elements (title, button, and input) for a more cohesive UX, or alternatively, align the required input with the button text.
Also applies to: 116-116
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/web/ui/modals/delete-group-modal.tsx(2 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-10-15T01:52:37.048Z
Learnt from: steven-tey
Repo: dubinc/dub PR: 2958
File: apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/members/page-client.tsx:270-303
Timestamp: 2025-10-15T01:52:37.048Z
Learning: In React components with dropdowns or form controls that show modals for confirmation (e.g., role selection, delete confirmation), local state should be reverted to match the prop value when the modal is cancelled. This prevents the UI from showing an unconfirmed change. The solution is to either: (1) pass an onClose callback to the modal that resets the local state, or (2) observe modal visibility state and reset on close. Example context: RoleCell component in apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/members/page-client.tsx where role dropdown should revert to user.role when UpdateUserModal is cancelled.
Applied to files:
apps/web/ui/modals/delete-group-modal.tsx
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
Summary by CodeRabbit
Tests
Chores
Style