Uh oh!
There was an error while loading. Please reload this page.
test(solid-query): assert exact values instead of loose matchers - #11105
Conversation
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
💤 Files with no reviewable changes (1)
📝 WalkthroughWalkthroughTests tighten Solid Query cache and mutation assertions by validating stored data values, cache isolation, explicit ChangesSolid Query test assertions
Estimated code review effort: 1 (Trivial) | ~5 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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 |
View your CI Pipeline Execution ↗ for commit cc8615f
☁️ Nx Cloud last updated this comment at |
Uh oh!
There was an error while loading. Please reload this page.
🎯 Changes
Continues the recent test-quality series (e.g. #11057, #11093) by converting the
toBeTruthy()/toBeFalsy()/toBeDefined()assertions insolid-querytests to exact assertions:QueryClientProvider— cache presence checks now assert the exact cached value (?.state.data) produced by the test'squeryFn, and the cross-cache absence checks in the partitioning test usetoBeUndefined()instead ofnot.toBeDefined(). One redundant existence check was removed where the next line already asserts?.options.gcTimeon the same query (it fails onundefinedeither way).suspense— the cache absence check before mount usestoBeUndefined()instead oftoBeFalsy().useQuery— after the first fetch in the client-switch test, the presence check onqueryClient1's cache now asserts the exact cached value.mutationOptions— removedexpect(lastSnapshot[1]).toBeFalsy(): the precedingexpect(lastSnapshot.length).toEqual(1)already guarantees there is no second entry.One
toBeDefined()is intentionally left in place: inuseQuery→ "should refetch query when queryClient changes", tightening thequeryClient2cache check to?.state.datafails. AftersetClient(queryClient2), the secondqueryFncall actually lands inqueryClient1's cache (itsdataUpdateCountgoes to 2) while the entry inqueryClient2's cache staysstatus: 'pending'/fetchStatus: 'idle'and never fetches. This looks like an observer re-subscription ordering issue inuseBaseQuery(in theon(client, ...)computed,createClientSubscriber()is called beforesetObserver(newObserver), so the subscription attaches to the old observer). I'd rather report and fix that separately than encode the current behavior into an exact assertion here.After this,
grep -rE 'toBeTruthy\(\)|toBeFalsy\(\)|toBeDefined\(\)' packages/solid-query/srconly matches the site described above.✅ Checklist
Local verification detail:
vitest runon the four edited files — 162 tests passed, no type errors;test:eslintand prettier clean; full-suite failure set identical tomainin the same environment.🚀 Release Impact
Summary by CodeRabbit