Form Validation Test Cases That Keep UI and API Rules Aligned

The Minimum Form Validation Smoke Test

When release time is limited, start with these ten cases.

The smoke set checks the central validation contract. It does not replace field-specific security, accessibility, localization or business-rule coverage.

Define the Validation Contract Before Writing Cases

A form field should not be described only as "valid" or "invalid." For each field or field relationship, define the rule that every layer should enforce.

Example validation contract

Separate Validation from Normalization

Validation answers whether a value is allowed. Normalization answers which equivalent representation should be stored or compared.

"  Maria  " -> "Maria"
"+31 20 123 4567" -> normalized phone representation
"[email protected]" -> identity-policy representation
Unicode composed form -> selected canonical form

For every normalized field, test that the application accepts the supported input representation, stores the documented representation and does not change the user's intended meaning.

Use Systematic Data Selection Instead of Random Invalid Values

A strong validation suite needs small datasets selected from the rule, not hundreds of arbitrary strings.

Length boundary template

m - 1 -> rejected
m     -> accepted
n     -> accepted
n + 1 -> rejected

Numeric boundary template

9
10
11
99
100
101

Cross-field truth table

Conditional-field table

Required and Optional Field Test Cases

A required indicator must be visible and programmatically associated with the field. Do not rely only on color or an unexplained asterisk.

Length, Range, Number and Date Test Cases

Native constraints such as required, minlength, maxlength, min, max, step, type and pattern improve browser feedback but do not replace server enforcement.

Format, Whitespace and Unicode Test Cases

Do Not Mistake Strictness for Correctness

The values O'Connor, Anne-Marie, [email protected], 020 1234 5678 and localized numbers are not automatically invalid. Their validity depends on field purpose, supported locales, identity policy, normalization rules and downstream system requirements.

Treating names as ASCII letters only

Human names are not reliable identifiers and do not follow one global character pattern.

Treating phone numbers as numeric values

Phone numbers can contain leading zeros, country prefixes, spaces and separators. They are normally identifiers represented as text.

Rejecting plus-addressed email without a product rule

An application can define an identity policy, but it should not reject a supported address merely because a simplistic pattern does not anticipate it.

Removing punctuation from free-form text

Filtering punctuation is not a primary defence against injection. Output encoding, parameterized queries and context-specific controls are still required.

Parsing localized numbers without an explicit locale

1,500 and 1.500 can mean different values. The displayed format, parser and stored representation must agree.

Cross-Field, Conditional and Dynamic Validation Test Cases

Cross-field validation is different from validating two fields separately. Every individual value can satisfy its format while the combined state remains invalid.

Client, Server and API Parity Test Cases

Client-side validation provides immediate feedback, but every untrusted request must still be validated by the server.

Validation parity matrix

Client and server do not need identical timing or identical code. They need a compatible acceptance contract, with the server making the authoritative decision.

Error Message, Accessibility and Recovery Test Cases

Errors should identify the affected control, explain the problem in text, remain discoverable without relying only on color and preserve non-sensitive valid data after server-side redisplay.

The Most Important Form Validation Failure Patterns

The browser rejects a value that the API accepts

An outdated pattern, duplicated rule or simplified frontend check blocks legitimate data even though the server contract permits it.

The browser accepts a value that the API rejects

The rejection must map back to a useful field or form-level error without losing data.

One layer trims the value while another validates the raw value

Define whether normalization occurs before validation, after validation, only for storage or only for comparison, then apply that order consistently.

A hidden field continues blocking submission

Check visibility, disabled state, required state, custom validity, request inclusion and retained value when conditions change.

Correcting an error destroys valid data

Users should not need to reconstruct the entire form or re-enter all non-sensitive values after one validation error.

The server returns an error the UI cannot locate

Nested server error paths must map to visible controls or an understandable form-level summary.

{
  "errors": {
    "billing.address.postal_code": [
      "The postal code does not match the selected country."
    ]
  }
}

Validation is treated as the security control

Input validation is one layer. It does not replace output encoding, parameterized queries, authorization or context-specific security controls.

When Client and Server Rules May Differ Deliberately

The goal is not duplicated code for its own sake. The goal is one acceptance contract with appropriate enforcement at every boundary.

What Each Testing Layer Can Prove

A browser can show "Enter a valid email address." It cannot prove that the server rejects the same request after browser validation has been removed.

How to Select Validation Cases After a Change

Do not execute every negative string after every change. Run the cases that cross the changed rule, its boundaries and the layers enforcing it.

Automating Form Validation Test Cases

Many validation scenarios can reuse one browser flow:

Open the form
Fill fields from {{DATASET}}
Submit the form
Assert {{EXPECTED_FIELD_ERRORS}}
Assert {{EXPECTED_FORM_RESULT}}

A positive dataset can describe both inputs and expected results:

{
  "name": "minimum valid name",
  "values": {
    "displayName": "Li",
    "email": "[email protected]",
    "quantity": 10
  },
  "expected": {
    "accepted": true,
    "fieldErrors": {}
  }
}

A negative boundary case can reuse the same flow:

{
  "name": "name below minimum length",
  "values": {
    "displayName": "L",
    "email": "[email protected]",
    "quantity": 10
  },
  "expected": {
    "accepted": false,
    "fieldErrors": {
      "displayName": "Enter at least 2 characters"
    }
  }
}

Separate browser and API assertions

The browser flow should verify visible errors, focus, retained values, correction and successful resubmission. The API or integration layer should verify status codes, structured error bodies, server enforcement, normalization and the absence of invalid stored data.

Keep rule data centralized where practical

A stable validation schema may provide required, minimum, maximum, pattern, allowed values and dependencies. Generated cases still need review because schemas do not automatically describe useful error wording, legitimate Unicode, normalization order, semantic business rules, recovery behavior or accessibility.

What Browser Automation Should Not Claim

Browser automation should not be presented as proof of complete server-side enforcement, protection against SQL injection or XSS, safe database queries, absence of regex denial-of-service risk, secure file inspection, every Unicode normalization edge case, every locale-specific parsing rule, authorization, or safe handling of every oversized payload.

Browser automation remains valuable because it proves that real users can see, understand, correct and resubmit invalid form data.

Frequently Asked Questions

Should validation happen on blur or only on submit?

Use the interaction pattern defined for the product. Test the selected event sequence, correction behavior and accessibility instead of assuming one universal trigger.

Should the UI and API use exactly the same code?

Not necessarily. They need a compatible acceptance contract. Shared schemas can reduce drift but do not replace integration tests.

Should all special characters be rejected?

No. Permitted characters depend on the field. Apostrophes, hyphens, diacritics and non-Latin letters can be legitimate.

Is an invalid email address a security problem?

Usually it is first a data-quality and workflow problem. Email-format validation does not replace unrelated security controls.

Should server errors clear the form?

Usually no. Preserve valid non-sensitive data so the user can correct the problem. Sensitive fields may require a separate retention policy.

Form Validation Testing Checklist

Before approving form validation, confirm that one valid complete dataset is accepted, optional fields can be omitted, required fields reject empty and whitespace-only values, field groups expose one understandable required-state error, minimum and maximum boundaries use the intended inclusivity, numbers enforce type and range, dates use the intended calendar and timezone, every documented format has positive and negative cases, whitespace handling is explicit, supported Unicode is accepted, normalization occurs in a defined order, cross-field relationships use the complete form state, conditional fields update required and validity states, hidden fields do not block unexpectedly, browser constraints can be bypassed without bypassing the server, UI and API reach compatible acceptance decisions, server-only rejections map to useful visible errors, errors remain discoverable, valid non-sensitive data survives unsuccessful submission, successful retry creates one result, and mobile, paste, autofill and localized input are covered.

Final acceptance criterion. The final acceptance criterion is not: "Invalid values displayed a red error message." It is: "The same documented business rule accepted legitimate data and rejected invalid data at every relevant boundary, while preserving the user's valid input and providing a clear path to correction."

Automate the Repeatable Browser Layer

WrightTest lets teams record one reusable form flow, replace fixed values with named datasets, run each validation case independently and inspect screenshots, step results, errors and Playwright traces.

The browser checks can be exported to native Playwright .spec.ts files when they need to move into an existing repository or CI pipeline.

Use WrightTest to prove the visible validation and correction journey. Combine it with API, server, storage, accessibility and security checks to verify the complete validation contract.