test(query-devtools/utils): add tests for 'mutationSortFns'#10651
test(query-devtools/utils): add tests for 'mutationSortFns'#10651
Conversation
📝 WalkthroughWalkthroughThe PR extends a test file for query-devtools utilities by importing four additional utility functions and introducing a comprehensive test suite for ChangesMutation Sorting Function Tests
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
|
View your CI Pipeline Execution ↗ for commit 6066160
☁️ Nx Cloud last updated this comment at |
🚀 Changeset Version PreviewNo changeset entries found. Merging this PR will not cause a version bump for any packages. |
size-limit report 📦
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@packages/query-devtools/src/__tests__/utils.test.ts`:
- Around line 1108-1109: The tests assert exact comparator return values; update
the two assertions that call mutationDateSort(older, newer) and
mutationDateSort(newer, older) to assert sign rather than exact numbers —
replace the toBe(1) check with toBeGreaterThan(0) and the toBe(-1) check with
toBeLessThan(0) so the tests only require positive/negative results from
mutationDateSort when comparing older and newer.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 3ca13393-48de-43b4-8d2e-37ac54c95559
📒 Files selected for processing (1)
packages/query-devtools/src/__tests__/utils.test.ts
| expect(mutationDateSort(older, newer)).toBe(1) | ||
| expect(mutationDateSort(newer, older)).toBe(-1) |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For JavaScript Array.prototype.sort, must a comparator return exactly -1/0/1, or is any negative/zero/positive number valid?
💡 Result:
Any negative/zero/positive number is valid for the comparator in JavaScript Array.prototype.sort. The specification and documentation define the behavior based on the sign of the return value: less than 0 means a before b, 0 means equal (original order preserved where stable), greater than 0 means a after b [1][2][3]. Examples like numeric sorting with (a - b), which can return values like -60, are standard and recommended [4][1]. MDN explicitly uses < 0, === 0, > 0 in its table, not requiring exactly -1/0/1 [1]. While examples often show -1/0/1 for clarity, any value with the correct sign works, as sorting algorithms (like quicksort, timsort) only check the sign [1][5]. The ECMAScript spec's SortCompare abstract operation treats the result based on whether it's less than, equal to, or greater than zero after coercion [6][7]. Returning exactly -1/0/1 is a best practice for readability and to avoid large number precision issues with floats, but not required [1].
Citations:
- 1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort
- 2: https://udn.realityripple.com/docs/Web/JavaScript/Reference/Global_Objects/Array/sort
- 3: https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/TypedArray/sort
- 4: https://w3schools.w3schoolsapp.com/jsref/jsref_sort.html
- 5: https://thelinuxcode.com/sort-an-array-in-javascript-modern-patterns-for-2026/
- 6: Normative: A more precise Array.prototype.sort tc39/ecma262#1585
- 7: Array.prototype.sort specification problem tc39/ecma262#1369
🏁 Script executed:
# Check the test file content at the specified lines
sed -n '1108,1109p; 1128,1129p; 1144,1145p; 1160,1161p; 1176,1177p' packages/query-devtools/src/__tests__/utils.test.tsRepository: TanStack/query
Length of output: 647
🏁 Script executed:
# Find where mutationDateSort and mutationStatusSort are defined
rg -l "mutationDateSort|mutationStatusSort" packages/query-devtools/src --type ts --type tsxRepository: TanStack/query
Length of output: 86
🏁 Script executed:
# Find where mutationDateSort and mutationStatusSort are defined
rg "mutationDateSort|mutationStatusSort" packages/query-devtools/src -lRepository: TanStack/query
Length of output: 148
🏁 Script executed:
# Find and examine the implementations
rg "mutationDateSort|mutationStatusSort" packages/query-devtools/src/utils.tsx -A 5Repository: TanStack/query
Length of output: 599
Assert comparator sign, not exact -1/1.
While these comparators currently return exactly -1 and 1, the test assertions encode this implementation detail unnecessarily. JavaScript sort comparators only need to return negative/zero/positive values. Using toBeGreaterThan(0) and toBeLessThan(0) makes tests more resilient to refactoring—the assertions will pass if implementations return other signed values (e.g., 2 / -2), which is semantically correct for sorting.
Suggested update
- expect(mutationDateSort(older, newer)).toBe(1)
- expect(mutationDateSort(newer, older)).toBe(-1)
+ expect(mutationDateSort(older, newer)).toBeGreaterThan(0)
+ expect(mutationDateSort(newer, older)).toBeLessThan(0)
- expect(mutationStatusSort(paused, pending)).toBe(-1)
- expect(mutationStatusSort(pending, paused)).toBe(1)
+ expect(mutationStatusSort(paused, pending)).toBeLessThan(0)
+ expect(mutationStatusSort(pending, paused)).toBeGreaterThan(0)
- expect(mutationStatusSort(pending, success)).toBe(-1)
- expect(mutationStatusSort(success, pending)).toBe(1)
+ expect(mutationStatusSort(pending, success)).toBeLessThan(0)
+ expect(mutationStatusSort(success, pending)).toBeGreaterThan(0)
- expect(mutationStatusSort(error, success)).toBe(-1)
- expect(mutationStatusSort(success, error)).toBe(1)
+ expect(mutationStatusSort(error, success)).toBeLessThan(0)
+ expect(mutationStatusSort(success, error)).toBeGreaterThan(0)
- expect(mutationStatusSort(older, newer)).toBe(1)
- expect(mutationStatusSort(newer, older)).toBe(-1)
+ expect(mutationStatusSort(older, newer)).toBeGreaterThan(0)
+ expect(mutationStatusSort(newer, older)).toBeLessThan(0)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| expect(mutationDateSort(older, newer)).toBe(1) | |
| expect(mutationDateSort(newer, older)).toBe(-1) | |
| expect(mutationDateSort(older, newer)).toBeGreaterThan(0) | |
| expect(mutationDateSort(newer, older)).toBeLessThan(0) |
🤖 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 `@packages/query-devtools/src/__tests__/utils.test.ts` around lines 1108 -
1109, The tests assert exact comparator return values; update the two assertions
that call mutationDateSort(older, newer) and mutationDateSort(newer, older) to
assert sign rather than exact numbers — replace the toBe(1) check with
toBeGreaterThan(0) and the toBe(-1) check with toBeLessThan(0) so the tests only
require positive/negative results from mutationDateSort when comparing older and
newer.
1 participant
🎯 Changes
Add unit tests for the
mutationSortFnsrecord of mutation-sort helpers inquery-devtools/utils.tsx.mutationSortFnsexposes two string keys ('last updated','status') that map to comparators used to order mutations in the devtools panel.Cases:
'last updated'(mutationDateSort) — places the more recently submitted mutation first'status'(mutationStatusSort) — places paused mutations first, places pending and errored mutations before successful ones, and falls back to "last updated" sort within the same status rankEach test uses a real
Mutationinstance built viamutationCache.build.queryClient.clear()runs inafterEachto keep tests isolated.mutationDateSort's behavior whensubmittedAtvalues are equal is intentionally left unasserted while its intent is being clarified separately.✅ Checklist
pnpm run test:pr.🚀 Release Impact
Summary by CodeRabbit