Form Test Data Generator

What Test Cases Are Generated and Why

Manual form testing typically covers two scenarios: the happy path (valid data that the form accepts) and one or two obvious error cases (empty required field, wrong email format). That leaves ten categories of inputs untested — and those are the ones that cause real production bugs, security vulnerabilities, and database errors.

This tool generates 12 test case categories for every field in your form. Each category targets a different class of bug:

How to Use the Generated Data

The most effective workflow depends on whether your team does manual testing or automated testing — or both.

Manual testing workflow

1. Build your form in the constructor above (add fields, set types and constraints).
2. Open your application's form in the browser alongside this tool.
3. Click any cell in the table to copy its value to your clipboard.
4. Paste it into the corresponding field and submit.
5. Verify the application's response matches expectations: valid data is accepted, invalid data shows the correct error message, XSS payloads are not executed.

The table is organized by row (test category) and column (field), so you can run one category across all fields at once, or one field across all categories. Both approaches are valid depending on whether you're doing horizontal (cross-field) or vertical (per-field) test coverage.

Automated testing with Cypress

Export the test data as CSV, place it in your cypress/fixtures/ folder, then use it in a data-driven test:

// cypress/e2e/form.cy.ts
import Papa from 'papaparse';

describe('Registration form', () => {
  before(() => {
    cy.fixture('test-data.csv').then(raw => {
      const { data } = Papa.parse(raw, { header: true });
      Cypress.env('testCases', data);
    });
  });

  it('handles all test categories for email field', () => {
    Cypress.env('testCases').forEach(row => {
      cy.visit('/register');
      cy.get('[name="email"]').type(row.email);
      cy.get('[type="submit"]').click();

      if (row._category === 'Valid (happy path)') {
        cy.url().should('include', '/dashboard');
      } else {
        cy.get('.error-message').should('be.visible');
      }
    });
  });
});

Automated testing with Playwright

// tests/form.spec.ts
import { test, expect } from '@playwright/test';
import { parse } from 'papaparse';
import fs from 'fs';

const raw = fs.readFileSync('tests/fixtures/test-data.csv', 'utf-8');
const { data } = parse<Record<string, string>>(raw, { header: true });

for (const row of data) {
  test(`form — ${row._category}`, async ({ page }) => {
    await page.goto('/register');
    await page.fill('[name="email"]', row.email);
    await page.fill('[name="username"]', row.username);
    await page.click('[type="submit"]');

    if (row._category === 'Valid (happy path)') {
      await expect(page).toHaveURL(/dashboard/);
    } else {
      await expect(page.locator('.error')).toBeVisible();
    }
  });
}

Field Types and What Gets Generated Per Type

Each field type maps to a specific set of test values per category. Here is the reference for the most important field types and their edge-case behaviours:

Email

Email validation is notoriously hard to get right. RFC 5321 allows addresses up to 254 characters total, with a 64-character local part and a 255-character domain. Common validator mistakes include: rejecting valid plus-addressing (user+tag@example.com), rejecting subdomains, or accepting strings that are structurally valid but have no TLD. The Boundary max case sends a 254-character address to verify your validator handles the RFC limit, not an arbitrary shorter limit.

XSS payload for email: "><script>alert(1)</script>@x.com — this tests whether your application escapes the email value before rendering it in HTML (e.g., in a confirmation email preview or admin panel).

Number

The boundary and range cases use the exact min and max values you configure. The Invalid format case sends the string abc to test that your backend validates type, not just the frontend. The Special characters case sends 1e308 (larger than JavaScript's Number.MAX_VALUE) to test floating-point overflow. The Oversized case sends 309 digits — more than a 64-bit float can represent — to test integer overflow in server-side code.

Password

The Boundary minimum case sends exactly minLength characters, which is the most common place for off-by-one errors in password validators. The Unicode case sends P@$$w0rd™️🔐 — emoji in passwords are valid UTF-8 and should be accepted, but they cause issues with bcrypt implementations that silently truncate at 72 bytes (bcrypt's internal limit), meaning two passwords that look different might hash to the same value.

Select / dropdown

The most important test for select fields is the Invalid format case, which sends INVALID_OPTION — a value not in the options list. This tests whether your backend validates the enum value server-side, or whether it trusts the frontend select element. Frontend validation is bypassed trivially with browser DevTools or a direct API call; backend validation is mandatory.

Edge Cases Your Form Validation Should Handle

Beyond the 12 generated categories, here is a checklist of edge cases that break most custom validation logic:

• Whitespace-only strings: " " passes if (value) checks in many languages because a non-empty string is truthy. Always trim and check length after trimming.
• Zero-width characters: Unicode U+200B (zero-width space), U+200C (zero-width non-joiner), and U+200D (zero-width joiner) are invisible in most UIs but count as characters in string length. A username of "user​" (with zero-width space) and "user" look identical but are different strings.
• Null bytes: The character U+0000 (null byte) terminates strings in C-based backends. Sending a null byte in a form field can truncate string values or bypass length checks in languages that use C string functions.
• Newlines in single-line fields: Text inputs accept \n via programmatic input even when the browser UI shows one line. A first-name field containing a newline can break CSV exports, email headers (CRLF injection), and single-line database columns.
• Surrogate pairs: Emoji like 😀 are encoded as surrogate pairs in UTF-16, so "😀".length === 2 in JavaScript despite being one visible character. A maxLength=10 validator using .length will allow 5 emoji (10 code units) even though the user sees only 5 characters, potentially overflowing a database column sized for 10 characters.
• Right-to-left override character: U+202E forces right-to-left text direction for all following characters. Used in filenames and form fields to disguise gpj.exe as exe.jpg (reversed). Test especially on file name fields and user-display fields.
• The number -0: In IEEE 754 floating point, -0 === 0 is true, but Object.is(-0, 0) is false. Some serializers produce "-0" in JSON; some parsers treat it as zero, others as a negative zero. Test number fields with -0 if your backend does financial or physics calculations.
• Date edge cases: February 29 only exists in leap years. January 1, 1970 (Unix epoch) and December 31, 9999 (common max date) can trigger parsing errors in date libraries that don't handle extremes. Test date fields with 2024-02-29 (valid leap date), 2023-02-29 (invalid — 2023 is not a leap year), 1970-01-01, and 9999-12-31.