thrilltrack-explorer/docs/TEST_DATA_GENERATOR.md

Test Data Generator

Overview

The Test Data Generator is a comprehensive testing utility that creates realistic submissions to test the moderation queue, versioning, and audit systems. It's accessible from Admin Settings > Testing tab.

Features

• Multiple Presets: Small, Medium, Large, and Stress test configurations
• Entity Type Selection: Choose which entities to generate (parks, rides, companies, etc.)
• Advanced Options: Dependencies, conflicts, version chains, escalations
• Test Data Marking: All generated data is marked with is_test_data: true
• Easy Cleanup: Clear all test data with one click

Usage

Accessing the Generator

1. Log in as a moderator or admin
2. Navigate to Admin Settings
3. Click the Testing tab
4. Configure your test data generation

Presets

Small (~30 submissions)

• Use Case: Quick sanity checks, basic functionality testing
• Contents: 5 parks, 10 rides, 3 companies, 2 ride models, 5 photo sets
• Features: Mixed field density, photo support
• Time: ~3-7 seconds

Medium (~125 submissions)

• Use Case: Standard testing, queue management validation
• Contents: 20 parks, 50 rides, 20 companies, 10 ride models, 25 photo sets
• Features: Full field variation, technical data, photos
• Time: ~15-30 seconds

Large (~600 submissions)

• Use Case: Performance testing, pagination verification
• Contents: 100 parks, 250 rides, 100 companies, 50 ride models, 100 photo sets
• Features: Complete field population, stats, specs, former names
• Time: ~60-120 seconds

Stress (~2600 submissions)

• Use Case: Load testing, database performance
• Contents: 400 parks, 1000 rides, 400 companies, 200 ride models, 500 photo sets
• Features: Maximum data density, all technical data, hundreds of photos
• Time: ~4-7 minutes

Entity Types

Select which entity types to generate:

• Parks: Theme parks, amusement parks, water parks (with locations, operators, property owners)
• Rides: Roller coasters, flat rides, water rides, dark rides (with technical specs, coaster stats, former names)
• Manufacturers: Companies that build rides
• Operators: Companies that operate parks
• Property Owners: Companies that own park properties
• Designers: Individuals/companies that design rides
• Ride Models: Specific ride model types from manufacturers
• Photos: Photo submissions with 1-10 photos each, captions, metadata

Field Population Density

Control how many optional fields are populated:

Mixed (Recommended)

• Distribution: 10% minimal, 20% basic, 40% standard, 20% complete, 10% maximum
• Most Realistic: Matches real-world usage patterns
• Tests: All levels of data completeness

Minimal

• Fields: Required fields only
• Use: Test minimum viable submissions
• Performance: Fastest generation

Standard

• Fields: Required + 50% optional
• Use: Balanced testing scenario
• Performance: Moderate generation time

Maximum

• Fields: All fields + technical data
• Includes: Coaster stats, technical specs, former names
• Use: Complete data testing
• Performance: Slowest generation

Advanced Options

Include Dependencies

• Creates parent-child relationships (e.g., rides linked to parks)
• Tests dependency resolution in moderation queue
• Essential for realistic testing scenarios

Include Conflicts

• Generates submissions with missing dependencies
• Creates duplicate slug scenarios
• Tests error handling and conflict resolution

Include Version Chains

• Creates multiple edits on the same entity
• Tests versioning system and rollback functionality
• Validates field-level change tracking

Include Escalated Items

• Marks some submissions as high priority
• Tests escalation workflow
• Priority queue sorting validation

Include Expired Locks

• Creates submissions with expired moderator locks
• Tests auto-release mechanism
• Queue cleanup validation

Test Data Structure

All test submissions include:

{
  "content": {
    "action": "create",
    "metadata": {
      "is_test_data": true,
      "generated_at": "2024-01-15T10:30:00Z",
      "generator_version": "1.0.0",
      "preset": "medium"
    }
  }
}

This metadata allows:

• Easy identification in database queries
• Selective cleanup without affecting real data
• Version tracking of test data generator

Cleanup

Clear All Test Data

1. Click Clear All Test Data button
2. Confirm the action in the dialog
3. All submissions with is_test_data: true will be deleted
4. Process includes:
   • Deletion of content_submissions records
   • Cascade deletion of related submission_items
   • Cascade deletion of type-specific tables
   • Removal of photo submissions
   • Cleanup of version history

Note: This only removes test data. Real user submissions are never affected.

Testing Scenarios

Basic CRUD Testing

1. Generate Small preset with all entity types
2. Navigate to Moderation Queue
3. Claim and approve a park submission
4. Verify park appears in database
5. Clear test data when done

Dependency Resolution

1. Generate Medium preset with dependencies enabled
2. Find a ride submission that depends on a new park
3. Approve the park first
4. Verify ride can now be approved
5. Check that park ID is correctly linked

Queue Management

1. Generate Large preset with escalated items
2. Verify escalated items appear at top of queue
3. Test claiming and lock expiration
4. Verify priority sorting works correctly

Performance Testing

1. Generate Stress preset
2. Navigate to moderation queue
3. Test pagination performance
4. Test filtering and search performance
5. Monitor database query times

Version Chain Testing

1. Generate Medium preset with version chains
2. Find an entity with multiple edits
3. View version history
4. Test rollback functionality
5. Verify field-level changes tracked

Best Practices

During Development

• Use Small preset for quick iterations
• Enable only the entity types you're testing
• Clear test data frequently to avoid clutter

Before Deployment

• Run Medium preset with all options
• Verify all workflows complete successfully
• Test with Large preset for performance baseline

Performance Testing

• Use Stress preset on staging environment
• Monitor database performance metrics
• Test concurrent moderator scenarios

Data Management

• Clear test data after each testing session
• Never deploy with test data in production
• Document any test data used in demos

Troubleshooting

Generation Fails

• Check browser console for errors
• Verify moderator permissions
• Check edge function logs in Supabase dashboard
• Ensure database connection is stable

Slow Generation

• Large/Stress presets take time (expected)
• Check database performance
• Verify edge function timeout settings
• Consider generating in smaller batches

Cannot Clear Test Data

• Verify test data exists (check stats display)
• Check RLS policies on content_submissions
• Ensure cascade delete is configured
• Check edge function permissions

Test Data Appears in Production

• Never run generator in production
• Use separate testing/staging environment
• If accidentally run, use Clear All Test Data immediately
• Verify with database query that test data is removed

Technical Details

Implementation Files

• Service: src/lib/testDataGenerator.ts
• UI Component: src/components/admin/TestDataGenerator.tsx
• Seed Function: supabase/functions/seed-test-data/index.ts
• Integration: src/pages/AdminSettings.tsx

Database Tables Used

• content_submissions - Main submission records
• submission_items - Individual submission items
• park_submissions - Park-specific data
• ride_submissions - Ride-specific data
• company_submissions - Company-specific data
• ride_model_submissions - Ride model-specific data

Security

• Requires moderator role
• Uses service role key for bulk operations
• Rate limited to prevent abuse
• All operations logged in audit trail

Future Enhancements

Planned features:

• Photo submission generation
• Report/moderation flag generation
• Custom seed configuration
• Export/import test scenarios
• Automated test suite integration
• Performance benchmarking tools

Support

For issues or questions:

1. Check edge function logs in Supabase dashboard
2. Review browser console for client errors
3. Verify database schema matches expectations
4. Check RLS policies are correctly configured