@inputcn/testing

Drive an inputcn field from a test the way a user would.

Documentation · The contract · All 11 components

Typing into a masked field from a test is its own small nightmare. These helpers do it properly — keystroke by keystroke, through the component's own handlers.

Install

npm i @inputcn/testing

Usage

import { fillCurrency, leaveField, expectInvalid } from "@inputcn/testing"

it("rejects a budget over the cap", async () => {
  const { field } = renderField(<CurrencyInput label="Budget" max={100000} />)

  await fillCurrency(field, 250000)
  await leaveField(field)

  // Asserts the RULE, not the sentence. Rewording the copy cannot break this.
  expectInvalid(field, "max")
})

What makes it different

• 11 fill helpers. One per component, each driving it to a canonical value.
• Rule-based assertions. expectInvalid(field, "max") reads the data-rule attribute, so tests survive a copy change.
• Three render modes. renderField, renderInForm and renderManaged — standalone, native form, and form-library.

Entry points

Every module is importable on its own, so you take only what you use.

| Import | What it is | |---|---| | @inputcn/testing | Everything below, re-exported | | @inputcn/testing/fill | The 11 fill* helpers and pasteInto | | @inputcn/testing/assert | expectValue, expectInvalid, expectWarning, expectFormData | | @inputcn/testing/render | renderField, renderInForm, renderManaged |

Accessibility

Keyboard complete, labelled, and errors announced once through role="alert" rather than on every keystroke. 50 axe-core checks run on every commit.

[!CAUTION] Screen readers have not been verified yet. Until they are, this library is structurally accessible, not screen-reader verified. The full audit, including what is untested and why, is in ACCESSIBILITY.md.

Part of inputcn — the inputs shadcn/ui doesn't ship. Not affiliated with or endorsed by shadcn.