Skip to content

test(tar-xz): cover toAsyncIterable across Node and Browser variants#124

Merged
oorabona merged 1 commit into
masterfrom
test/tarxz-async-iterable-coverage
Apr 30, 2026
Merged

test(tar-xz): cover toAsyncIterable across Node and Browser variants#124
oorabona merged 1 commit into
masterfrom
test/tarxz-async-iterable-coverage

Conversation

@oorabona
Copy link
Copy Markdown
Owner

Summary

35 new vitest cases parametrized across the two internal/to-async-iterable.{ts,browser.ts} implementations. Both files were 0% / 28.57% covered before — the ArrayBuffer, Iterable, AsyncIterable, ReadableStream, and NodeJS.Readable paths were untested.

Approach

Direct imports of both files in a single packages/tar-xz/test/to-async-iterable.spec.ts. Node 18+ has ReadableStream in globalThis, so both implementations run directly without JSDOM. describe.each parametrizes shared cases across both ; Node-only and Browser-only contracts get separate describe blocks.

Smart trick

Real ReadableStream instances on Node 18+ have BOTH Symbol.asyncIterator AND getReader. Since both implementations check Symbol.asyncIterator first, a real stream takes the fast path. To force the webReadableToAsyncIterable (getReader-only) path through coverage, a makeGetReaderOnlyStream fake provides only getReader. Locks the contract for that path.

Contracts locked

  • null and numberTypeError (both impls).
  • string → resolves through the Symbol.iterator branch (NOT a TypeError ; this is current behavior, locked verbatim).
  • Browser-only : custom AsyncIterable returned by reference (no Readable.from wrapping).
  • Node-only : Readable.from wraps even existing Readable (verified by reference comparison).

Coverage

File Before After
to-async-iterable.ts 28.57% 100% (27/27 lines, 20/20 branches, 5/5 fns)
to-async-iterable.browser.ts 0.00% 100% (25/25 lines, 18/18 branches, 5/5 fns)
tar-xz overall 86.96% lines / 82.1% branches 95.33% lines / 89.45% branches

Diff

1 new file, +289 lines (test only, no source change).

Gates

  • pnpm install --frozen-lockfile: EXIT 0
  • pnpm --filter tar-xz build: EXIT 0
  • pnpm type-check: EXIT 0
  • pnpm exec biome check .: EXIT 0, 0 warnings
  • pnpm test: tar-xz 155 → 190 passing (+35), 3 skipped unchanged ; full workspace 489 root + 190 tar-xz + 63 nxz = 742 passing, 0 fail

Test plan

  • CI green
  • Codecov reflects to-async-iterable {.ts,.browser.ts} both at 100%

The two internal/to-async-iterable.{ts,browser.ts} implementations had
0% coverage on the browser file and 28.57% on the Node one — the
ArrayBuffer, Iterable, AsyncIterable, and ReadableStream paths were
all untested.

Add 35 cases parametrized via describe.each across both
implementations (Node 18+ has ReadableStream in globalThis, so both
files run directly without JSDOM):

- All accepted input types: Uint8Array, Buffer, ArrayBuffer,
  Iterable, AsyncIterable, ReadableStream, NodeJS.Readable.
- Empty cases for every iterable input shape.
- Error contract: null and number reject with TypeError; string
  resolves via the Symbol.iterator branch (locked behavior, not a
  bug).
- A makeGetReaderOnlyStream fake forces the webReadableToAsyncIterable
  path even on Node where ReadableStream natively supports
  Symbol.asyncIterator.
- A Browser-only assertion locks the contract that custom
  AsyncIterables are returned by reference (no Readable.from
  wrapping in the browser variant).

Coverage:
- to-async-iterable.ts:        28.57% → 100% (27/27 lines, 20/20
  branches, 5/5 functions).
- to-async-iterable.browser.ts: 0% → 100% (25/25 lines, 18/18
  branches, 5/5 functions).
- tar-xz overall: 86.96% lines / 82.1% branches → 95.33% lines /
  89.45% branches.

35 new vitest cases, 0 source changes; tar-xz suite goes from 155
to 190 passing.
@oorabona oorabona merged commit 8c0f994 into master Apr 30, 2026
6 checks passed
@oorabona oorabona deleted the test/tarxz-async-iterable-coverage branch April 30, 2026 15:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant