test(e2e): mosaic UserButton e2e test coverage - #9357
Conversation
The mocked vitest suite already owns every rendered surface and every outbound call. These assert only what it cannot reach: whether Clerk acted on the call, whether the server sees the result, whether clerk-js renders into the DOM the Mosaic tree hands it, and that the app resolves the entry with no @clerk/ui installed.
🦋 Changeset detectedLatest commit: 5ec39b1 The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Six failures the first real run surfaced: - The page used SignedIn/SignedOut, which @clerk/nextjs does not export. Show with when='signed-in' is the current API. - The popup selector matched on substring, so 'Account' also matched clerk-js's 'Account panel'. Exact now. - The only organization is already active on sign-in, so its row is the current item rather than a button. Personal is selected first, then the organization. - Manage account lives behind the account row's actions menu, not on the popup. - The inflated 90s/180s timeouts were compensating for a stale local registry, not real slowness. Back to the repo default.
@clerk/astro
@clerk/backend
@clerk/chrome-extension
@clerk/clerk-js
@clerk/electron
@clerk/electron-passkeys
@clerk/eslint-plugin
@clerk/expo
@clerk/expo-google-signin
@clerk/expo-passkeys
@clerk/express
@clerk/fastify
@clerk/hono
@clerk/localizations
@clerk/nextjs
@clerk/nuxt
@clerk/react
@clerk/react-router
@clerk/shared
@clerk/tanstack-react-start
@clerk/testing
@clerk/ui
@clerk/upgrade
@clerk/vue
commit: |
API Changes Report
Summary
@clerk/testingCurrent version: 2.2.18 Subpath
|
`useUserProfilePages` hardcodes the UserProfile's built-in page list as a mirror of clerk-js, and nothing at any level asserted the mirror was accurate. `openOrNavigate` was covered only by asserting `navigate` was called with a string, never that the app landed there.
Description
Stacked on #9338.
The experimental Mosaic
UserButtonhad no integration coverage.packages/ui/src/mosaic/user-button/__tests__/already holds 137 cases against a mocked Clerk, covering every rendered surface and every outbound call with its exact arguments. None of that is repeated here. This adds only what the mock cannot observe:GET /api/merather than through thesetActiveargument.<SignIn />in<SignedOut>takes over.UserProfilemodal, with auserProfileProps.customPagesentry rendering inside it. That portal from the SDK tree into a clerk-js-owned node is the riskiest seam in the feature, and vitest can only portal into a container the mock handed back.useUserProfilePageshardcodes the pages theUserProfilebrings itself, mirroring clerk-js rather than reading from it, because the profile is not mounted at the point the order has to be decided. Nothing asserted the mirror was accurate; the vitest suite checks the order is forwarded, against a list it also supplies. Ordering a custom page ahead of every built-in makes the rendered nav readable as an assertion about the list, in both directions: a built-in the mirror does not name lands ahead of the custom page, and one it names that clerk-js does not have is dropped as invalid page data.openOrNavigateis the widest configuration branch in the controller, and every case asserted only thatnavigatewas called with a string. AuserProfileUrlnow has to actually land on the app's page, with no modal behind it.@clerk/ui. The app is built without.addDependency('@clerk/ui', PKGLAB), and the last case asserts it is absent from the installed@clerk/nextjsand@clerk/reactmanifests too. That guards the inlining feat(nextjs): export Mosaic UserButton from an experimental subpath #9338 relies on: if the Mosaic entry ever regresses to importing@clerk/uiat runtime, everything still resolves in the monorepo and breaks only for consumers.The new
mosaicUserButtonpage object is built on roles and accessible names, since Mosaic renders nodata-testidand no component-scoped classnames. Every name is taken fromuser-button.view.tsx. The suite currently has no accessibility assertions anywhere, so this makes each case double as one.The suite runs green locally against a real development instance. Two things it settled along the way: the layout imports
@clerk/nextjs/experimental/mosaic/styles.cssdirectly rather than through a layered@import, and the popup selector has to match its accessible name exactly, because clerk-js labels the legacy popover "Account panel" and role-name matching is substring by default.Checklist
pnpm testruns as expected.pnpm buildruns as expected.Type of change