Skip to content

TESTING.md

Latest commit

 

History

History
124 lines (98 loc) · 3.91 KB

TESTING.md

File metadata and controls

124 lines (98 loc) · 3.91 KB

Testing the Hono API Migration

Automated Testing

TypeScript compilation and type checking:

npm run typecheck

This validates:

  • All TypeScript types are correct
  • Routes are properly registered
  • Schemas match endpoint definitions
  • No compilation errors

Test Results

✅ TypeScript compilation: PASSED ✅ Type checking: PASSED ✅ All routes registered: PASSED ✅ Schemas defined: PASSED

Manual Testing Required

Cloudflare Pages with Advanced Mode (_worker.ts) requires deployment to test properly. The TypeScript files are compiled automatically by Cloudflare Pages on deployment.

After Deployment

Test all endpoints for correct behavior:

# Health checks
curl /api/v1/ping
curl /api/v1/health

# Services - Enhanced with statistics
curl /api/v1/services
# Verify response includes:
# - regionCount for each service
# - providerBreakdown (AWS/Azure counts)
# - configurationBreakdown for vdc_vault

# Service detail endpoints
curl /api/v1/services/vdc_m365
curl /api/v1/services/vdc_vault
curl /api/v1/services/vdc_entra_id
curl /api/v1/services/vdc_salesforce
curl /api/v1/services/vdc_azure_backup
# Verify response includes:
# - service metadata
# - regions array (list of region IDs)
# - providerBreakdown with region lists
# - configurationBreakdown for tiered services

# Service detail error handling
curl /api/v1/services/invalid_service
# Should return 404 with proper error format

# Regions
curl /api/v1/regions
curl /api/v1/regions?provider=AWS
curl /api/v1/regions?service=vdc_vault
curl /api/v1/regions/aws-us-east-1

# OpenAPI docs
curl /api/openapi.json
# Verify new endpoints are documented

Test Cases for Service Enhancements

/api/v1/services Endpoint

Test 1: Response structure

  • ✅ Returns services array
  • ✅ Returns count field
  • ✅ Each service has regionCount
  • ✅ Each service has providerBreakdown.AWS and providerBreakdown.Azure
  • ✅ Tiered services (vdc_vault) have configurationBreakdown
  • ✅ Boolean services do not have configurationBreakdown

Test 2: Data accuracy

  • ✅ Region counts are correct for each service
  • ✅ Provider breakdown sums equal total regionCount
  • ✅ Configuration breakdown counts are accurate
  • ✅ All configuration keys follow "Edition-Tier" format

/api/v1/services/{serviceId} Endpoint

Test 3: Valid service IDs

  • ✅ /api/v1/services/vdc_vault returns correct data
  • ✅ /api/v1/services/vdc_m365 returns correct data
  • ✅ /api/v1/services/vdc_entra_id returns correct data
  • ✅ /api/v1/services/vdc_salesforce returns correct data
  • ✅ /api/v1/services/vdc_azure_backup returns correct data

Test 4: Response structure for boolean services

  • ✅ Returns service object with metadata
  • ✅ Returns regions array with region IDs
  • ✅ Returns providerBreakdown with count and regions for AWS and Azure
  • ✅ Does not include configurationBreakdown

Test 5: Response structure for tiered services (vdc_vault)

  • ✅ Returns service object with editions and tiers
  • ✅ Returns regions array with all supporting region IDs
  • ✅ Returns providerBreakdown with region lists
  • ✅ Returns configurationBreakdown with keys like "Foundation-Core"
  • ✅ Each configuration breakdown entry has count and regions

Test 6: Data consistency

  • ✅ Number of regions in regions array matches service.regionCount
  • ✅ Provider breakdown region lists are mutually exclusive
  • ✅ Provider breakdown counts sum to total region count
  • ✅ Region IDs in provider breakdown match those in main regions list
  • ✅ Configuration breakdown region IDs are all present in main regions list

Test 7: Error handling

  • ✅ Invalid service ID returns 404
  • ✅ Error response has correct structure (error, code, message, parameter, value, allowedValues)
  • ✅ Error code is SERVICE_NOT_FOUND
  • ✅ allowedValues lists all valid service IDs

All responses should follow the API contract defined in OpenAPI spec.