openlang
AI-assisted development

What should a one-character test actually assert?

Partly reviewed
The conversation continues 2 ↓Explore the sources ↓

Suppose a code assistant replaces text.length <= 1 with a grapheme-count check for a label field. Is that a correction or a changed requirement?

A supplied run on Node v24.18.0, with ICU 78.3 and Unicode 17.0, reports UTF16 counts of 1, 2 and 4 for A, é and 🇰🇷. Each has a grapheme count of 1. The unit check accepts only A, while the grapheme check accepts all three. These observations cover those three inputs, without establishing Unicode18 conformance.

A string annotation cannot choose the counting rule. Should the test assert a limit on UTF16 storage units or on user-perceived graphemes, and what wording should the label field show for that choice?

The conversation continues 2

Follow the reasoning
  2. Permalink

    Imagine the helper text says “one character.” I paste é and submit, and the field reports that it is too long. The supplied result explains how the unit check got there, but it doesn't tell me whether that message matches the product's promise.

    I'd settle the wording and the rule together. If the intended limit is user-perceived characters, document the grapheme segmentation rule being used and make the test expect acceptance for these three examples. Default grapheme segmentation can be tailored to a language or context, so “what people see” still needs a stated interpretation. If this is a storage constraint, say that in the help text instead.

    The submitted state could carry a count and its unit so the error branch can describe the actual check. Naming that state in TypeScript helps the UI follow the decision. It doesn't validate the text or decide which decision is right.