OUT-3671: setup vitest and add DropboxClient isolation test#100
OUT-3671: setup vitest and add DropboxClient isolation test#100SandipBajracharya merged 2 commits intomainfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Add vitest + vite-tsconfig-paths, alias `server-only` to a local empty stub (Next.js bundler normally swaps it; Vitest has no equivalent), and seed env placeholders so server modules with Zod-validated env imports don't blow up at test load time. First test asserts DropboxClient, its dbxAuthClient, and the underlying SDK authInstance are fresh per construction — locking in the per-instance convention so a future module-level cache fails CI loudly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
446bd53 to
8e34ccd
Compare
Greptile SummaryThis PR wires up Vitest as the test runner with proper TypeScript path-alias support and a Confidence Score: 5/5Safe to merge — test-infrastructure only change with no production code paths altered. No P0 or P1 findings. All three client-tree layers are correctly asserted. Env stubs are safe. The vitest config is minimal and correct. The previous review comments about missing getDropboxClient() assertions have been fully addressed in the final test file. No files require special attention. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[vitest run] --> B[vitest.setup.ts\nInjects placeholder env vars via ??=]
B --> C[DropboxClient.isolation.test.ts]
C --> D[Test 1: different refresh tokens]
C --> E[Test 2: same refresh token]
D --> F[new DropboxClient\nrefreshTokenA]
D --> G[new DropboxClient\nrefreshTokenB]
E --> H[new DropboxClient\nrefreshTokenA]
E --> I[new DropboxClient\nrefreshTokenA]
F --> J{Assert isolation}
G --> J
H --> K{Assert isolation}
I --> K
J --> L[dbxAuthClient not same ref]
J --> M[authInstance not same ref]
J --> N[getDropboxClient not same ref]
K --> L
K --> M
K --> N
subgraph Config
V[vitest.config.ts]
V --> P[tsconfigPaths plugin\n@ alias resolution]
V --> Q[server-only alias\n to test/stubs/server-only.ts]
V --> R[environment: node]
end
Reviews (2): Last reviewed commit: "test(OUT-3671): cover clientInstance and..." | Re-trigger Greptile |
Per Greptile review: the prior assertions covered dbxAuthClient and authInstance but not clientInstance — the actual SDK object used for every Dropbox API call. A module-level cache of clientInstance (e.g. Map<refreshToken, Dropbox>) would pass the prior assertions while still introducing a cross-tenant credential leak. Consolidated into two tests, each asserting all three layers (dbxAuthClient, authInstance, getDropboxClient()) for both the different-refresh-token and identical-refresh-token scenarios so the matrix is symmetric and complete. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary
vitest,vite-tsconfig-paths, Node environment, tsconfig path-alias support,server-onlystub, env placeholders for Zod-validated server modules.pnpm test(run-once) andpnpm test:watchscripts.src/lib/dropbox/__tests__/DropboxClient.isolation.test.ts— locks in the per-instance isolation invariant forDropboxClient/DropboxAuthClient/ underlying SDKauthInstanceso a future module-level cache fails CI loudly.object !== 'link'check, atomic&&instead of mistaken||).Scope note
The isolation test verifies a constructor-level structural invariant only — it is a regression tripwire, not a proof of absence of cross-tenant credential leaks. That claim still rests on the manual code audit captured in OUT-3671's description.
Test plan
pnpm testpasses locally (3/3)pnpm typecheckcleanpnpm lintcleanDropboxAuthClientcauses the isolation test to fail (verified during development)Follow-ups (tracked, not in this PR)
pnpm testinto.husky/pre-pushpnpm teston every PR🤖 Generated with Claude Code