Explore this last-name form, then ask your AI coding agent to generate boundary tests from its actual source. Separate what the code does from what the product ought to support.
What can you discover?
The implementation trims whitespace, permits only ASCII letters, and caps input at 20 JavaScript string units. That is code—not an approved product requirement.
Try the boundary presets and name formats. Notice the difference between typing into a maxlength field and assigning a longer value programmatically.
Challenge the rule: should people with longer names, accents, spaces, apostrophes, or hyphens be excluded?
Use synthetic names only. This fixture sends no requests and saves no profile.
Open form separately ↗2. Give the agent the implementation
Inspect the full form source
3. Generate boundary tests—and question the limits
Generate boundary test cases from the attached last-name form implementation. Analyze it read-only; do not modify it yet.
Separate two groups:
1. Implementation-characterization tests: derive expected results from the actual code. Cover empty input, whitespace, 1/19/20/21-character values, trimming before length validation, allowed and rejected characters, and typing/pasting versus programmatic assignment beyond maxlength. Explain that JavaScript string.length counts UTF-16 code units, not necessarily user-perceived characters.
2. Product-rule challenges: propose tests for longer names, spaces, apostrophes, hyphens, accented characters, non-Latin scripts, and Unicode normalization. Do not assume the current 20-character ASCII-only rule is correct. State the intended-behavior question or requirement needed to judge each case. Do not invent a universal legal maximum or a “longest name” fact.
For each case provide a synthetic input, its relevant length, how to enter it, expected behavior according to this code, the product expectation (or unresolved question), and a brief rationale. Prioritize the cases most likely to expose exclusion or inconsistent validation. Keep front-end observations separate from unknown server behavior.
Also return proposed tests as an OpenTest.ai otai/testcase v1 JSON array using title and goal, with optional steps (description, action, target, value, expected) when useful. Make unresolved product expectations explicit; do not invent pass/fail outcomes. Keep source-derived characterization separate from desired product behavior. Preserve the original form unchanged. This is test generation, not evidence that the tests have executed.
OpenTest.ai test-case format ↗