Project 30: Form Automation Engine - Smart Data Entry
Project 30: Form Automation Engine - Smart Data Entry
Build an intelligent form-filling system that uses Claude’s reasoning to understand form context, generate appropriate test data, handle validation errors, and complete multi-step workflows.
Quick Reference
| Attribute | Value |
|---|---|
| Difficulty | Advanced |
| Time Estimate | 1-2 weeks |
| Language | TypeScript (Alternatives: JavaScript, Python) |
| Prerequisites | Project 29 (Visual Page Analyzer), form validation concepts |
| Key Topics | Form automation, test data generation, validation handling, session management |
| Main Book | “Testing Web Applications” by Hung Q. Nguyen |
1. Learning Objectives
By completing this project, you will:
- Analyze form structure semantically: Understand form fields by their context, not just their HTML attributes
- Generate contextual test data: Create realistic but fake data appropriate for each field type
- Handle validation intelligently: Detect validation errors, understand them, and adapt
- Manage multi-step workflows: Track state across form wizards and multi-page flows
- Coordinate browser tools: Chain form_input, read_page, and navigation tools effectively
- Build retry logic: Implement intelligent retry strategies for transient failures
2. Theoretical Foundation
2.1 Form Semantics: Beyond HTML Attributes
Forms communicate meaning through multiple channels:
┌─────────────────────────────────────────────────────────────────────────────┐
│ Form Field Semantics │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │
│ │ Explicit │ │ Implicit │ │ Contextual │ │
│ │ Signals │ │ Signals │ │ Signals │ │
│ └───────────────┘ └───────────────┘ └───────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ - type="email" - name="pwd" - "Billing" section │
│ - type="tel" - id="dob" - Near "credit card" │
│ - type="date" - placeholder - After "shipping" │
│ - required attr - autocomplete - Form title/heading │
│ - pattern attr - aria-label - Field grouping │
│ - label element - class names - Other field values │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Key Insight: Claude’s reasoning capability allows analyzing all these signals together, making smarter decisions than simple pattern matching.
2.2 HTML5 Form Elements and Validation
| Input Type | Purpose | Validation | Example Test Data |
|---|---|---|---|
text |
General text | Pattern, minlength, maxlength | “John Doe” |
email |
Email address | Email format validation | “test42857@example.com” |
password |
Secure input | minlength, pattern | “SecureP@ss2024!” |
tel |
Phone number | Pattern | “+1 (555) 123-4567” |
url |
Web address | URL format | “https://example.com” |
number |
Numeric input | min, max, step | “42” |
date |
Date picker | min, max dates | “2024-12-25” |
select |
Dropdown | Required selection | (pick from options) |
checkbox |
Boolean toggle | Required | true/false |
radio |
Single choice | Required selection | (pick from group) |
file |
File upload | Accept types | (special handling) |
2.3 Client-Side vs Server-Side Validation
Form Submission Flow:
User Input ──▶ Client Validation ──▶ Server Validation ──▶ Success/Error
│ │
▼ ▼
Immediate May redirect
feedback or show error
(red border, (page reload,
error text) toast message)
┌─────────────────────────────────────────────────────────────────────────────┐
│ Validation Detection Points │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Client-Side: Server-Side: │
│ ───────────── ──────────── │
│ • HTML5 constraint validation • Form rejection with error message │
│ • JavaScript validation events • Field-specific error markers │
│ • Inline error messages • Toast/alert notifications │
│ • Field border/style changes • Page redirect to error state │
│ • aria-invalid attribute • JSON error response (AJAX) │
│ • Form :invalid pseudo-class • HTTP 400/422 status codes │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
2.4 Multi-Step Form Patterns
Common multi-step (wizard) form patterns:
Pattern 1: Single Page with Steps
┌─────────────────────────────────────────┐
│ Step 1 ──▶ Step 2 ──▶ Step 3 │
│ [Account] [Profile] [Confirm] │
│ │
│ Only one section visible at a time │
│ State stored in JavaScript │
└─────────────────────────────────────────┘
Pattern 2: Multi-Page Flow
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Page 1 │───▶│ Page 2 │───▶│ Page 3 │
│ /signup │ │/signup/2 │ │/signup/3 │
└──────────┘ └──────────┘ └──────────┘
│ │
└────── Session/Cookie ──────────┘
Pattern 3: Modal Sequence
┌─────────────────────────────────────────┐
│ Main Page │
│ ┌───────────────┐ │
│ │ Modal 1 │──▶ Modal 2 ──▶ ... │
│ │ [Details] │ │
│ └───────────────┘ │
└─────────────────────────────────────────┘
2.5 Test Data Generation Strategies
| Strategy | When to Use | Example |
|---|---|---|
| Random + Suffix | Email uniqueness | testuser_${timestamp}@example.com |
| Faker patterns | Realistic looking data | “John Smith”, “123 Main St” |
| Edge cases | Testing validation | “a@b.c” (min valid email) |
| Boundary values | Numeric limits | min-1, min, max, max+1 |
| Format specific | Pattern matching | SSN: “123-45-6789” |
3. Project Specification
3.1 What You Will Build
A form automation system that:
- Discovers forms on any page
- Classifies each field’s expected data type
- Generates appropriate test data
- Fills forms intelligently
- Detects and handles validation errors
- Tracks multi-step form progress
- Reports results with detailed logs
3.2 Functional Requirements
- Form Discovery
- Find all forms on a page
- Identify form boundaries
- Map field relationships (password confirmation, etc.)
- Field Classification
- Determine expected data format
- Identify required vs optional
- Detect dependent fields (country → state)
- Data Generation
- Create contextually appropriate data
- Generate unique values when needed
- Handle special formats (SSN, phone, etc.)
- Form Filling
- Enter data in correct order
- Handle select dropdowns
- Toggle checkboxes appropriately
- Validation Handling
- Detect client-side errors
- Adapt and retry with different data
- Track which approaches worked
- Multi-Step Support
- Track current step
- Navigate between steps
- Maintain state across pages
3.3 Example Interaction
You: Fill out the signup form at https://example.com/signup with test data
Claude: I'll analyze the form and fill it appropriately.
[Navigating to signup page...]
[Analyzing form structure...]
================================================================================
FORM ANALYSIS: example.com/signup
================================================================================
FORM DISCOVERED: Signup Form (6 fields)
---------------------------------------
Field Analysis:
1. Full Name [text, required] → Classified as: PERSON_NAME
2. Email [email, required] → Classified as: EMAIL
3. Password [password, required] → Classified as: PASSWORD
Pattern: (?=.*\d)(?=.*[a-z])(?=.*[A-Z])
4. Confirm Password[password, required] → Classified as: PASSWORD_CONFIRM
5. Country [select, required] → Classified as: COUNTRY_SELECT
6. Terms [checkbox, required] → Classified as: TERMS_CHECKBOX
Dependencies Detected:
- Password ↔ Confirm Password (must match)
FILLING FORM
------------
Generating test data...
Full Name: "Test User 42857"
Email: "testuser42857@example.com"
Password: [generated: 16 chars, meets pattern]
Confirm Password: [matching]
Country: "United States"
Terms: [will check]
Filling fields...
[ref_1] Full Name........... DONE
[ref_2] Email............... DONE
[ref_3] Password............ DONE
[ref_4] Confirm Password.... DONE
[ref_5] Country............. DONE
[ref_6] Terms............... DONE
Checking for validation errors...
VALIDATION ERROR DETECTED
-------------------------
Message: "Email already exists"
Field: Email
Strategy: Generate new unique email
New value: "testuser42858@example.com"
Retrying...
RETRY SUCCESSFUL
----------------
Form filled successfully!
Actions available:
1. Submit the form
2. Generate different test data
3. Show the generated credentials
What would you like to do?
4. Solution Architecture
4.1 High-Level Design
┌─────────────────────────────────────────────────────────────────────────────┐
│ Form Automation Engine │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Form │──▶│ Field │──▶│ Data │──▶│ Form │ │
│ │ Discovery │ │ Classifier │ │ Generator │ │ Filler │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────────────────┐ │
│ │ Report │◀──│ Retry │◀──│ Validation Detector │ │
│ │ Generator │ │ Engine │ │ │ │
│ └──────────────┘ └──────────────┘ └──────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
4.2 Field Classification System
┌─────────────────────────────────────────────────────────────────────────────┐
│ Field Classifier Logic │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Input: Field element from accessibility tree │
│ │
│ Signal Extraction: │
│ ┌─────────────────────────────────────────────────────────────────────────┐ │
│ │ type: "password" │ │
│ │ name: "confirmPassword" │ │
│ │ label: "Confirm your password" │ │
│ │ placeholder: "Re-enter password" │ │
│ │ autocomplete: "new-password" │ │
│ │ aria-describedby: "password-hint" │ │
│ │ pattern: "(?=.*\d)(?=.*[a-z])" │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
│ │
│ Classification Rules (priority order): │
│ │
│ 1. "password" AND ("confirm" OR "repeat" OR "verify") → PASSWORD_CONFIRM │
│ 2. type="password" → PASSWORD │
│ 3. type="email" OR name contains "email" → EMAIL │
│ 4. type="tel" OR name contains "phone" → PHONE │
│ 5. name contains "ssn" OR "social" → SSN │
│ 6. name contains "zip" OR "postal" → POSTAL_CODE │
│ 7. name contains "first" AND "name" → FIRST_NAME │
│ 8. name contains "last" AND "name" → LAST_NAME │
│ 9. type="date" OR name contains "dob" → DATE │
│ 10. type="number" → NUMBER │
│ 11. type="url" → URL │
│ 12. <select> element → SELECT (analyze options) │
│ 13. type="checkbox" → CHECKBOX (check context) │
│ 14. Default → TEXT │
│ │
│ Output: Field classification + generation strategy │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
4.3 Data Generation Patterns
┌─────────────────────────────────────────────────────────────────────────────┐
│ Data Generation Patterns │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ EMAIL: │
│ Pattern: testuser_{random_id}@example.com │
│ Example: testuser_42857@example.com │
│ Retry: Increment random_id │
│ │
│ PASSWORD: │
│ Requirements: Parse from pattern attribute or defaults │
│ Default: 16 chars, 1 upper, 1 lower, 1 digit, 1 special │
│ Example: SecureP@ss2024! │
│ │
│ PHONE: │
│ US Format: (555) 123-{random 4 digits} │
│ Example: (555) 123-4567 │
│ │
│ DATE: │
│ Past: Random date 18-65 years ago (for DOB) │
│ Future: Random date within 1 year (for appointments) │
│ Format: YYYY-MM-DD (HTML5 standard) │
│ │
│ NAME: │
│ Pattern: "Test User {random_id}" │
│ First: "Test" │
│ Last: "User_{random_id}" │
│ │
│ ADDRESS: │
│ Street: "123 Test Street" │
│ City: "Testville" │
│ State: "CA" (or from options) │
│ Zip: "90210" │
│ │
│ SELECT: │
│ Strategy: Pick first non-placeholder option │
│ Or: Match common patterns (United States, etc.) │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
4.4 Validation Error Detection Flow
Form Fill ──▶ Check Validation ──▶ Error Detected?
│
┌──────────────┴──────────────┐
│ │
YES NO
│ │
▼ ▼
┌──────────────────────┐ ┌──────────────┐
│ Parse Error Message │ │ Success │
│ Identify Field │ │ Report │
│ Determine Strategy │ └──────────────┘
└──────────────────────┘
│
▼
┌──────────────────────┐
│ Strategy Selection │
├──────────────────────┤
│ "already exists" │──▶ Generate new unique value
│ "invalid format" │──▶ Try different format
│ "too short/long" │──▶ Adjust length
│ "doesn't match" │──▶ Sync related fields
│ "required" │──▶ Fill missing field
│ Unknown │──▶ Report to user
└──────────────────────┘
│
▼
┌──────────────────────┐
│ Apply Fix & Retry │
│ (max 3 attempts) │
└──────────────────────┘
5. Implementation Guide
5.1 Chrome MCP Tools for Form Handling
form_input - Fill Form Fields
// Fill a text field
mcp__claude-in-chrome__form_input({
tabId: 12345,
ref: "ref_1", // Element reference from read_page
value: "test@example.com"
})
// Check a checkbox
mcp__claude-in-chrome__form_input({
tabId: 12345,
ref: "ref_5",
value: true // Boolean for checkboxes
})
// Select dropdown option
mcp__claude-in-chrome__form_input({
tabId: 12345,
ref: "ref_3",
value: "United States" // Match option text or value
})
find - Locate Form Elements
// Find specific form elements
mcp__claude-in-chrome__find({
tabId: 12345,
query: "email input field"
})
// Find error messages
mcp__claude-in-chrome__find({
tabId: 12345,
query: "error message or validation warning"
})
computer - Click and Type
// Click submit button
mcp__claude-in-chrome__computer({
action: "left_click",
ref: "ref_submit",
tabId: 12345
})
// Type with keyboard (for special cases)
mcp__claude-in-chrome__computer({
action: "type",
text: "test@example.com",
tabId: 12345
})
// Press Enter to submit
mcp__claude-in-chrome__computer({
action: "key",
text: "Enter",
tabId: 12345
})
5.2 Implementation Phases
Phase 1: Form Discovery (Days 1-2)
Goal: Find and analyze all forms on a page.
Tasks:
- Navigate to test page
- Use
read_pagewith filter “interactive” to find form elements - Group elements by form (look for form boundaries)
- Extract field attributes (type, name, required, pattern)
Checkpoint: Successfully list all form fields with their attributes.
Example output:
Form 1: "Signup" (6 fields)
- email [email, required]
- password [password, required, pattern: ...]
- ...
Phase 2: Field Classification (Days 3-4)
Goal: Classify each field by semantic type.
Tasks:
- Implement classification rules (see 4.2)
- Handle ambiguous cases with context
- Detect field dependencies (password confirmation)
- Test on various form types
Checkpoint: Accurate classification for common field types.
Phase 3: Data Generation (Days 5-6)
Goal: Generate appropriate test data for each field type.
Tasks:
- Implement generators for each classification
- Handle password requirements (parse patterns)
- Generate unique identifiers (timestamps, random)
- Coordinate dependent fields
Checkpoint: Generate valid data that passes client validation.
Phase 4: Form Filling (Days 7-8)
Goal: Fill forms reliably using generated data.
Tasks:
- Fill fields in logical order
- Handle different input types (select, checkbox, radio)
- Wait for dynamic updates
- Verify filled values
Checkpoint: Successfully fill complete forms.
Phase 5: Validation Handling (Days 9-10)
Goal: Detect and recover from validation errors.
Tasks:
- Check for error messages after filling
- Parse error text to identify issue
- Implement retry strategies
- Track attempt history
Checkpoint: Automatically recover from common validation errors.
Phase 6: Multi-Step Forms (Days 11-14)
Goal: Handle wizard-style multi-page forms.
Tasks:
- Detect when form continues to next step
- Track state across steps
- Navigate forward/backward
- Handle step validation
Checkpoint: Complete multi-step registration flows.
6. Testing Strategy
6.1 Test Scenarios
| Scenario | Test URL/Description | Expected Behavior |
|---|---|---|
| Simple form | Basic contact form | Fill and submit successfully |
| Validation | Form with strict patterns | Handle validation, retry |
| Select fields | Country/state dropdowns | Select appropriate options |
| Multi-step | Registration wizard | Navigate all steps |
| Error recovery | “Email exists” error | Generate new email, retry |
6.2 Test Data Patterns
// Test data generator pseudocode
const generateTestData = (fieldType, attempt = 0) => {
const timestamp = Date.now();
const uniqueId = `${timestamp}_${attempt}`;
switch(fieldType) {
case 'EMAIL':
return `testuser_${uniqueId}@example.com`;
case 'PASSWORD':
return generateSecurePassword();
case 'PHONE':
return `(555) ${100 + attempt}-${1000 + timestamp % 9000}`;
case 'NAME':
return `Test User ${uniqueId}`;
// ... more types
}
};
7. Common Pitfalls & Debugging
7.1 Frequent Issues
| Issue | Symptom | Solution |
|---|---|---|
| Field not fillable | form_input returns error | Check if field is editable, not disabled |
| Select not working | Value not selected | Try matching option text exactly |
| Validation not detected | Form seems submitted but isn’t | Check for dynamic error messages |
| Password mismatch | Confirm password fails | Ensure same value used for both |
| CAPTCHA blocking | Form won’t submit | Report to user (cannot automate) |
7.2 Debugging Techniques
// 1. Check page state after each action
mcp__claude-in-chrome__computer({ action: "screenshot", tabId })
// 2. Look for error messages
mcp__claude-in-chrome__find({
tabId,
query: "error message or alert"
})
// 3. Check console for JavaScript errors
mcp__claude-in-chrome__read_console_messages({
tabId,
pattern: "error|validation|failed"
})
// 4. Re-read page to see current state
mcp__claude-in-chrome__read_page({
tabId,
filter: "interactive"
})
8. Real World Outcome
When you complete this project, here’s a complete form automation session:
You: Fill out and submit the registration at https://example.com/register
Claude: I'll analyze and fill the registration form.
[Navigating to registration page...]
[Analyzing form structure...]
================================================================================
FORM AUTOMATION: example.com/register
================================================================================
STEP 1 OF 3: Account Details
-----------------------------
Fields Discovered:
1. Email Address [email, required]
2. Username [text, required, minlength: 3]
3. Password [password, required]
Requirements: 8+ chars, 1 uppercase, 1 number
4. Confirm Password [password, required]
Generating data...
Email: testuser_1703520000@example.com
Username: testuser_1703520000
Password: SecureP@ss2024!
Filling form...
Email.............. DONE
Username........... DONE
Password........... DONE
Confirm Password... DONE
Clicking "Next"...
VALIDATION ERROR: Username already taken
Strategy: Append random suffix
New value: testuser_1703520000_a7f3
Retrying...
Username........... DONE
Clicking "Next"... SUCCESS
STEP 2 OF 3: Profile Information
--------------------------------
Fields Discovered:
1. Full Name [text, required]
2. Phone [tel, optional]
3. Country [select, required]
4. State [select, optional] // Dependent on Country
Generating data...
Full Name: Test User
Phone: (555) 123-4567
Country: United States
State: California
Filling form...
Full Name.......... DONE
Phone.............. DONE
Country............ DONE
[Waiting for state options to load...]
State.............. DONE
Clicking "Next"... SUCCESS
STEP 3 OF 3: Preferences & Confirmation
---------------------------------------
Fields Discovered:
1. Newsletter [checkbox, optional]
2. Terms [checkbox, required]
3. Privacy Policy [checkbox, required]
Filling form...
Newsletter......... SKIPPED (optional)
Terms.............. CHECKED
Privacy Policy..... CHECKED
Ready to submit. Should I:
1. Click "Create Account" to complete registration
2. Review all entered data first
3. Go back and modify something
You: Submit it
Claude: Clicking "Create Account"...
REGISTRATION COMPLETE
---------------------
Success! Account created.
Redirected to: /welcome
Summary:
Email: testuser_1703520000@example.com
Username: testuser_1703520000_a7f3
Password: SecureP@ss2024!
These credentials have been displayed for testing purposes only.
Shall I take a screenshot of the confirmation page?
9. The Core Question You’re Answering
“How can Claude intelligently interact with forms rather than just filling fields blindly?”
This isn’t about mindlessly typing into input fields. The key insights:
- Claude understands context: “Confirm Password” isn’t just a password field - it must match the previous password
- Claude adapts to errors: A “username taken” error triggers a retry with a modified username
- Claude tracks state: Multi-step forms require remembering what was entered on previous steps
- Claude reasons about semantics: A “Country” dropdown affects what options appear in “State”
This is reasoning-driven automation, fundamentally different from recorded script playback.
10. Concepts You Must Understand First
Before starting this project, ensure you understand:
| Concept | Why It Matters | Where to Learn |
|---|---|---|
| HTML5 form elements | You’ll classify and fill every input type | MDN - HTML Forms |
| Form validation API | Understanding how browsers validate | MDN - Constraint Validation |
| CSS selectors for forms | Targeting specific inputs | MDN - Form CSS |
| HTTP form submission | What happens when a form posts | MDN - Sending Form Data |
| Session/cookies | How multi-step forms maintain state | MDN - HTTP Cookies |
| Accessibility tree | How form elements appear to screen readers | Project 29 learnings |
11. Questions to Guide Your Design
Work through these questions BEFORE implementing:
-
Field Ordering: Should you fill fields in DOM order or some other order? Does order affect validation?
-
Required vs Optional: How do you handle optional fields? Fill them? Skip them? Ask the user?
-
Error Classification: How do you distinguish between “email exists” (retry with new data) and “invalid email” (fix format)?
-
Password Patterns: How do you parse password requirements from pattern attributes or error messages?
-
Dependent Fields: How do you detect that “State” depends on “Country”? What’s the timing?
-
Multi-Step State: What happens if you need to go back a step? How do you track what was entered?
12. Thinking Exercise
Before implementing, trace through this form scenario:
<form action="/signup" method="POST">
<input name="email" type="email" required>
<input name="password" type="password"
minlength="8" pattern="(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).*">
<input name="password_confirm" type="password" required>
<select name="plan" required>
<option value="">Select a plan</option>
<option value="free">Free</option>
<option value="pro">Pro ($10/mo)</option>
</select>
<button type="submit">Sign Up</button>
</form>
Questions to answer on paper:
- What classification does each field receive?
- What test data would you generate?
- How do you ensure password_confirm matches password?
- What happens if the password doesn’t meet the pattern?
- Which option should be selected for “plan”?
- How would you detect a “password too weak” error?
13. The Interview Questions They’ll Ask
After completing this project, you’ll be ready for:
- “How would you automate testing of a multi-page form wizard?”
- Expected: State tracking, step detection, validation handling
- Bonus: Discuss back navigation, conditional steps
- “What’s your strategy for handling CAPTCHAs or bot detection?”
- Expected: Recognize limitations, graceful failure, user handoff
- Bonus: Discuss rate limiting, human verification patterns
- “How do you test form validation without submitting real data?”
- Expected: Test data generation, unique identifiers, cleanup
- Bonus: Discuss test environments, data isolation
- “What’s the difference between client and server validation?”
- Expected: Timing, reliability, user experience
- Bonus: Discuss validation bypass, security implications
- “How would you handle file upload fields in automation?”
- Expected: Recognize complexity, discuss alternatives
- Bonus: Discuss upload_image tool, mock files
14. Hints in Layers
If you get stuck, reveal hints progressively:
Hint 1: Form Discovery
Use read_page with filter “interactive” to find form elements. Look for patterns:
- “textbox” elements are text/email/password inputs
- “combobox” elements are select dropdowns
- “checkbox” and “radio” buttons for toggles
- “button” with “submit” for form submission
Group elements that appear together in the accessibility tree.
Hint 2: Field Classification
The accessibility tree includes labels and names. Look at:
textbox "Email Address" [ref_1]
→ Classification: EMAIL (from label)
textbox "password" [ref_2] (type: password)
→ Classification: PASSWORD (from type)
textbox "Confirm your password" [ref_3] (type: password)
→ Classification: PASSWORD_CONFIRM (from label + type)
Use multiple signals together for best classification.
Hint 3: Validation Detection
After filling and attempting submission:
- Wait briefly for validation (computer action: wait, duration: 1)
- Use
findto look for error messages - Re-read the page to check for changes
- Look for elements with “error”, “invalid”, “warning” in their text
Common error patterns:
- “Email already exists” → Generate new email
- “Password is too weak” → Add more complexity
- “Passwords don’t match” → Re-sync confirm field
Hint 4: Multi-Step Navigation
Detect step transitions by:
- URL changes (/step1 → /step2)
- New form elements appearing
- Previous fields disappearing
- Progress indicators changing
Track state in a structured way:
formState = {
currentStep: 2,
data: {
step1: { email: "...", password: "..." },
step2: { name: "...", phone: "..." }
},
completed: [1]
}
15. Books That Will Help
| Topic | Book | Chapter/Section |
|---|---|---|
| Form testing patterns | “Testing Web Applications” by Hung Q. Nguyen | Ch. 8 |
| Input validation | “Web Application Security” by Andrew Hoffman | Ch. 7 |
| Test automation | “The Art of Software Testing” by Glenford Myers | Ch. 5 |
| HTML forms | “HTML5: The Missing Manual” by Matthew MacDonald | Ch. 4 |
| Form UX | “Forms that Work” by Caroline Jarrett | All |
| Data generation | Faker.js Documentation | Examples section |
16. Extensions & Challenges
16.1 Beginner Extensions
- Save credentials: Output filled credentials to a file for reference
- Form templates: Pre-define data patterns for common form types
- Dry run mode: Analyze form without filling
16.2 Intermediate Extensions
- Fuzzing mode: Generate edge-case data to test validation
- Batch processing: Fill multiple forms from a data file
- Screenshot documentation: Capture each step for test evidence
16.3 Advanced Extensions
- Smart retry: Learn from errors to improve data generation
- Form diffing: Compare forms across page versions
- API integration: Submit via API when HTML form isn’t ideal
17. Learning Milestones
Track your progress through these checkpoints:
| Milestone | Description | Verification |
|---|---|---|
| 1. Form discovery | Can find and list all form fields | Field list matches manual inspection |
| 2. Classification | Correctly classify field types | Email, password, phone recognized |
| 3. Data generation | Generate valid test data | Data passes client validation |
| 4. Form filling | Fill all field types | Form shows entered data |
| 5. Validation handling | Detect and recover from errors | Retry works on “email exists” |
| 6. Multi-step | Complete wizard forms | Navigate all steps successfully |
This guide was expanded from CLAUDE_CODE_MASTERY_40_PROJECTS.md. For the complete learning path, see the project index.