managarten/TESTING_STRATEGY_AUTH_CREDITS.md

Comprehensive Testing Strategy: Authentication & Mana Credit System

Project: Manacore Monorepo - Central Auth & Credit System Version: 1.0 Date: 2025-11-25 Status: DRAFT

---

Executive Summary

This document provides a comprehensive testing strategy for the central authentication and mana credit system used across all Manacore applications (Memoro, Maerchenzauber, Manadeck, Picture, Chat). The strategy covers functional testing, security testing, integration testing, performance testing, and acceptance criteria.

Critical Business Paths

1. User Registration → Authentication → Service Access
2. Credit Purchase → Balance Update → Credit Consumption → Balance Deduction
3. Multi-App Credit Visibility & Usage
4. Token Refresh & Session Management

---

1. Authentication Testing

1.1 Registration Flow Tests

TC-AUTH-REG-001: Email/Password Registration

Priority: P0 (Critical) Description: User creates account with email and password

Test Steps:

1. Submit valid email and password (8+ chars, complexity requirements)
2. Verify account created in database
3. Check email verification sent (if applicable)
4. Verify tokens generated (manaToken, appToken, refreshToken)
5. Confirm tokens stored securely

Expected Results:

• User record created with UUID
• Three tokens generated and returned
• Tokens stored in secure storage (SecureStore on mobile, localStorage on web)
• Email verification sent if configured
• User can access protected routes

Edge Cases:

• Email already exists → 409 error with appropriate message
• Invalid email format → 400 error
• Weak password → 400 error with requirements
• Network timeout during registration → Retry mechanism
• Duplicate concurrent registrations → Second request fails

Test Data:

{
  valid: { email: "test+valid@example.com", password: "SecureP@ss123" },
  duplicate: { email: "existing@example.com", password: "AnyP@ss123" },
  invalid_email: { email: "not-an-email", password: "SecureP@ss123" },
  weak_password: { email: "test@example.com", password: "123" }
}

TC-AUTH-REG-002: Google Sign-In Registration

Priority: P0 (Critical)

Test Steps:

1. Initiate Google OAuth flow
2. User authorizes in Google
3. Receive idToken from Google
4. Submit idToken to /auth/google-signin
5. Verify account created or linked
6. Check tokens generated

Expected Results:

• New user: Account created with Google profile data
• Existing user: Linked to existing account
• Email extracted from Google profile
• Standard token set issued

Edge Cases:

• Invalid idToken → 401 error
• Google service unavailable → Graceful error message
• Email conflict with existing email/password account → Link accounts

TC-AUTH-REG-003: Apple Sign-In Registration

Priority: P1 (High)

Test Steps:

1. Initiate Apple Sign In flow
2. User authorizes in Apple
3. Receive identityToken from Apple
4. Submit identityToken to /auth/apple-signin
5. Verify account created
6. Check tokens generated

Expected Results:

• Account created with Apple ID
• Email may be private relay email
• Tokens issued correctly
• User can access services

Edge Cases:

• Private email relay handling
• First-time vs returning user
• Revoked Apple credentials

1.2 Login Flow Tests

TC-AUTH-LOGIN-001: Successful Email/Password Login

Priority: P0 (Critical)

Test Steps:

1. Submit valid credentials to /auth/signin
2. Verify response contains all three tokens
3. Check tokens stored in secure storage
4. Verify user data extracted from appToken
5. Confirm access to protected resources

Expected Results:

• 200 status code
• Tokens returned: { appToken, refreshToken }
• manaToken embedded in appToken claims
• User email stored locally
• AuthContext updated with user state

Validation Points:

• Token structure: JWT format validation
• Token claims: sub (user ID), role, app_id, exp, iat
• Token expiration: appToken ~1 hour, refreshToken ~30 days
• Storage success: All tokens persisted

TC-AUTH-LOGIN-002: Invalid Credentials

Priority: P0 (Critical)

Test Steps:

1. Submit incorrect password
2. Submit non-existent email
3. Verify appropriate error messages
4. Check no tokens issued
5. Ensure secure storage remains empty

Expected Results:

• 401 Unauthorized status
• Error: INVALID_CREDENTIALS
• No tokens in response
• No data written to storage
• User remains unauthenticated

TC-AUTH-LOGIN-003: Email Not Verified

Priority: P1 (High)

Test Steps:

1. Create account without verifying email
2. Attempt login
3. Verify error response

Expected Results:

• 403 Forbidden status
• Error: EMAIL_NOT_VERIFIED
• Prompt to check email for verification link
• No tokens issued

TC-AUTH-LOGIN-004: Firebase User Password Reset Required

Priority: P1 (High)

Test Steps:

1. Login as Firebase-migrated user
2. Verify password reset error
3. Check reset flow initiated

Expected Results:

• 401 status with specific error code
• Error: FIREBASE_USER_PASSWORD_RESET_REQUIRED
• User directed to password reset flow
• Password reset email sent

1.3 Logout Flow Tests

TC-AUTH-LOGOUT-001: Standard Logout

Priority: P0 (Critical)

Test Steps:

1. Authenticate user
2. Call /auth/logout with refreshToken
3. Verify tokens cleared from storage
4. Check server-side session invalidated
5. Attempt to use old tokens

Expected Results:

• All tokens removed from secure storage
• Server-side refresh token invalidated
• Subsequent API calls with old tokens fail with 401
• User redirected to login screen
• AuthContext reset to unauthenticated state

TC-AUTH-LOGOUT-002: Logout with Network Failure

Priority: P2 (Medium)

Test Steps:

1. Authenticate user
2. Disable network
3. Call logout
4. Verify local cleanup happens

Expected Results:

• Local tokens cleared even if server unreachable
• User marked as logged out in UI
• Server-side cleanup attempted with retry
• Graceful error handling

1.4 Token Refresh Tests

TC-AUTH-REFRESH-001: Automatic Token Refresh on Expiry

Priority: P0 (Critical)

Test Steps:

1. Login with valid credentials
2. Wait for appToken to expire (or manually expire)
3. Make API call that triggers 401
4. Verify automatic refresh initiated
5. Check new tokens issued
6. Confirm original API call succeeds

Expected Results:

• TokenManager detects expiry
• Refresh endpoint called with refreshToken
• New appToken and refreshToken returned
• Tokens updated in storage
• Original API request retried and succeeds
• No user interaction required

Performance Criteria:

• Refresh completes in < 2 seconds
• User experiences no disruption
• UI shows loading state during refresh

TC-AUTH-REFRESH-002: Concurrent Refresh Prevention

Priority: P0 (Critical)

Test Steps:

1. Trigger multiple API calls simultaneously with expired token
2. Verify only ONE refresh request sent
3. Check all requests queued during refresh
4. Confirm all succeed after refresh completes

Expected Results:

• Single refresh promise shared
• Request queue manages pending calls
• All queued requests processed with new token
• No duplicate refresh attempts
• Queue timeout: 30 seconds max

Test Implementation:

// Simulate 5 concurrent API calls with expired token
const requests = Array(5).fill(null).map(() =>
  fetch('/api/protected-resource')
);
await Promise.all(requests);
// Verify only 1 refresh API call made

TC-AUTH-REFRESH-003: Refresh Token Expiration

Priority: P0 (Critical)

Test Steps:

1. Manually expire refreshToken
2. Attempt to refresh
3. Verify error handling
4. Check user logged out

Expected Results:

• Refresh fails with 401
• Error: "Session expired. Please sign in again."
• All tokens cleared
• User redirected to login
• Clear error message displayed

TC-AUTH-REFRESH-004: Device ID Change Detection

Priority: P1 (High)

Test Steps:

1. Login on device A
2. Copy tokens to device B (different device ID)
3. Attempt token refresh on device B
4. Verify security check fails

Expected Results:

• Refresh denied
• Error: "Device ID has changed. Please sign in again."
• Tokens invalidated
• User must re-authenticate

1.5 Session Management Tests

TC-AUTH-SESSION-001: Multi-Device Login

Priority: P1 (High)

Test Steps:

1. Login on device A (iOS)
2. Login same user on device B (Android)
3. Login same user on device C (Web)
4. Verify all devices have valid sessions
5. Test concurrent API calls from all devices

Expected Results:

• All devices independently authenticated
• Each device has unique refreshToken
• All devices share same user ID
• Concurrent usage works correctly
• Token refresh on one device doesn't affect others

TC-AUTH-SESSION-002: Multi-App Session Sharing

Priority: P0 (Critical)

Test Steps:

1. Login to Memoro app
2. Navigate to Maerchenzauber app
3. Verify SSO (single sign-on) behavior
4. Check credits visible across apps

Expected Results:

• User authenticated in both apps
• No duplicate login required (if SSO configured)
• Credit balance synchronized
• App-specific JWT claims present (app_id)

TC-AUTH-SESSION-003: Session Persistence

Priority: P1 (High)

Test Steps:

1. Login to app
2. Close app completely
3. Reopen app after 1 hour
4. Verify user still authenticated
5. Check token validity

Expected Results:

• User remains logged in
• Tokens loaded from secure storage
• If appToken expired, automatic refresh occurs
• Seamless user experience

1.6 Password Management Tests

TC-AUTH-PWD-001: Password Reset Request

Priority: P1 (High)

Test Steps:

1. Submit forgot password request with email
2. Check email sent
3. Verify reset link format and expiration
4. Click link and reset password
5. Login with new password

Expected Results:

• Reset email sent to valid addresses
• Link expires after 24 hours
• Old password no longer works
• New password immediately usable

TC-AUTH-PWD-002: Rate Limiting on Password Reset

Priority: P2 (Medium)

Test Steps:

1. Request password reset
2. Immediately request again
3. Repeat 5 times
4. Verify rate limiting applied

Expected Results:

• First request succeeds
• Subsequent requests blocked
• Error: "Too many attempts. Please wait before trying again."
• Rate limit: Max 3 requests per 15 minutes

---

2. Credit System Testing

2.1 Credit Purchase Flow Tests

TC-CREDIT-PURCHASE-001: Successful Credit Purchase (Mock Payment)

Priority: P0 (Critical)

Test Steps:

1. User selects credit package (e.g., 100 credits for €4.99)
2. Initiate checkout with mock payment gateway
3. Simulate successful payment webhook
4. Verify credit balance updated
5. Check transaction recorded

Expected Results:

• Payment gateway returns success
• Webhook processed by backend
• Credit balance increased by purchased amount
• Transaction record created with:
  • Transaction ID
  • User ID
  • Amount (credits)
  • Timestamp
  • Status: "completed"
  • Payment method

Validation Points:

• Balance update is atomic (no partial updates)
• Duplicate webhook handling (idempotency)
• Transaction logged for audit

Test Data:

{
  packages: [
    { credits: 100, price: 4.99, productId: "mana_100" },
    { credits: 500, price: 19.99, productId: "mana_500" },
    { credits: 1000, price: 34.99, productId: "mana_1000" }
  ]
}

TC-CREDIT-PURCHASE-002: Failed Payment

Priority: P0 (Critical)

Test Steps:

1. Initiate credit purchase
2. Simulate payment failure (declined card)
3. Verify no credits added
4. Check appropriate error message

Expected Results:

• Credit balance unchanged
• No transaction record created (or marked "failed")
• User notified of payment failure
• Retry option presented

TC-CREDIT-PURCHASE-003: Duplicate Payment Webhook

Priority: P0 (Critical)

Test Steps:

1. Complete successful purchase
2. Replay same webhook notification
3. Verify idempotent handling

Expected Results:

• First webhook: Credits added
• Duplicate webhook: Ignored (detected by transaction ID)
• Balance not double-credited
• Log warning about duplicate webhook

Implementation:

// Idempotency check
const existingTx = await db.getTransaction(webhookData.transactionId);
if (existingTx) {
  console.log('Duplicate webhook ignored');
  return { status: 'already_processed' };
}

TC-CREDIT-PURCHASE-004: Webhook Timeout/Retry

Priority: P1 (High)

Test Steps:

1. Simulate slow/failed webhook delivery
2. Payment gateway retries webhook
3. Verify eventual consistency

Expected Results:

• Webhook processed on retry
• Credits eventually added
• User sees updated balance
• No duplicate credits

2.2 Credit Balance Tests

TC-CREDIT-BALANCE-001: Balance Check Endpoint

Priority: P0 (Critical)

Test Steps:

1. Authenticate user
2. Call /auth/credits endpoint
3. Verify response format
4. Check balance accuracy

Expected Results:

• 200 status code
• Response: { credits: number, max_credit_limit: number, id: string }
• Balance matches database
• Request completes in < 500ms

TC-CREDIT-BALANCE-002: Balance Consistency Across Apps

Priority: P0 (Critical)

Test Steps:

1. Login to Memoro app
2. Check credit balance
3. Login to Maerchenzauber app (same user)
4. Check credit balance
5. Verify balances identical

Expected Results:

• Same balance in both apps
• Real-time updates propagated
• No sync delays

TC-CREDIT-BALANCE-003: Negative Balance Prevention

Priority: P0 (Critical)

Test Steps:

1. User has 5 credits remaining
2. Attempt operation requiring 10 credits
3. Verify operation blocked
4. Check balance unchanged

Expected Results:

• 400 Bad Request
• Error: insufficient_credits
• Response includes: { requiredCredits: 10, availableCredits: 5 }
• Balance remains at 5
• No operation performed

2.3 Credit Consumption Tests

TC-CREDIT-CONSUME-001: Standard Credit Deduction

Priority: P0 (Critical)

Test Steps:

1. User has 100 credits
2. Perform operation costing 10 credits (e.g., create story)
3. Verify validation before operation
4. Perform operation
5. Deduct credits after success
6. Check final balance

Expected Results:

• Pre-operation validation: hasCredits: true
• Operation completes successfully
• Credits deducted: 10
• Final balance: 90
• Transaction logged

Implementation Pattern:

// 1. VALIDATE before operation
const validation = await creditClient.validateCredits(userId, 'STORY_CREATE', 10);
if (!validation.hasCredits) {
  throw insufficientCreditsError;
}

// 2. PERFORM operation
const story = await createStory(data);

// 3. CONSUME after success
await creditClient.consumeCredits(userId, 'STORY_CREATE', 10,
  `Created story: ${story.id}`, { storyId: story.id }
);

TC-CREDIT-CONSUME-002: Operation Failure (No Charge)

Priority: P0 (Critical)

Test Steps:

1. User has 100 credits
2. Validate credits (passes)
3. Operation fails (e.g., AI service error)
4. Verify NO credits deducted
5. Check balance unchanged

Expected Results:

• Validation: hasCredits: true
• Operation fails with error
• Credits NOT consumed
• Balance remains at 100
• User can retry

Critical Rule: NEVER charge credits for failed operations

TC-CREDIT-CONSUME-003: Concurrent Credit Deduction

Priority: P0 (Critical)

Test Steps:

1. User has 100 credits
2. Trigger 3 operations simultaneously (30 credits each)
3. Verify only 3 operations succeed
4. Check final balance correct

Expected Results:

• All 3 operations validate successfully
• All 3 operations complete
• Total deducted: 90 credits
• Final balance: 10 credits
• No race condition causing over-deduction or under-deduction

Database Implementation:

-- Atomic credit deduction with optimistic locking
UPDATE user_profiles
SET credits = credits - ${amount},
    updated_at = NOW()
WHERE id = ${userId}
  AND credits >= ${amount}
  AND updated_at = ${previousUpdatedAt}
RETURNING credits;

TC-CREDIT-CONSUME-004: Credit Deduction with Insufficient Balance (Edge Case)

Priority: P0 (Critical)

Test Steps:

1. User has 10 credits
2. Two concurrent operations (8 credits each)
3. Both validate simultaneously
4. First operation consumes 8 credits
5. Second operation attempts consumption
6. Verify second operation fails

Expected Results:

• Both validate successfully (balance check passes)
• First operation: Succeeds, balance → 2
• Second operation: Fails (insufficient balance)
• User refunded for second operation (if pre-charged)
• Clear error message

Race Condition Mitigation:

• Use database transactions
• Lock rows during deduction
• Validate again at consumption time

2.4 Credit Refund & Adjustment Tests

TC-CREDIT-REFUND-001: Failed Operation Refund

Priority: P1 (High)

Test Steps:

1. User purchases credits
2. Credits deducted for operation
3. Operation fails after deduction
4. Trigger refund process
5. Verify credits restored

Expected Results:

• Refund transaction created
• Credits added back to balance
• Original transaction marked "refunded"
• User notified of refund

TC-CREDIT-REFUND-002: Manual Credit Adjustment (Admin)

Priority: P2 (Medium)

Test Steps:

1. Admin logs in
2. Navigates to user credit management
3. Adds/removes credits manually
4. Provides reason
5. Verify balance updated

Expected Results:

• Balance adjusted by specified amount
• Adjustment logged with admin ID and reason
• User sees updated balance immediately

2.5 Credit Transaction History Tests

TC-CREDIT-HISTORY-001: View Transaction History

Priority: P2 (Medium)

Test Steps:

1. User performs multiple credit operations
2. Navigate to transaction history
3. Verify all transactions listed
4. Check pagination

Expected Results:

• All transactions displayed chronologically
• Each entry shows: Date, Operation, Amount, Balance
• Pagination for large histories
• Filter/search options

---

3. Security Testing

3.1 Authentication Security Tests

TC-SEC-AUTH-001: SQL Injection Prevention

Priority: P0 (Critical)

Test Steps:

1. Attempt login with SQL injection payloads:
   • admin'--
   • ' OR '1'='1
   • '; DROP TABLE users;--
2. Verify all rejected

Expected Results:

• All attempts fail with 400/401
• No database queries executed with injected SQL
• Input sanitized/parameterized

TC-SEC-AUTH-002: JWT Token Manipulation

Priority: P0 (Critical)

Test Steps:

1. Obtain valid JWT token
2. Modify claims (e.g., change user ID)
3. Re-sign with wrong secret
4. Submit modified token
5. Verify rejection

Expected Results:

• Signature validation fails
• 401 Unauthorized
• Request denied
• Original user unaffected

TC-SEC-AUTH-003: Token Expiration Enforcement

Priority: P0 (Critical)

Test Steps:

1. Obtain valid token
2. Wait for expiration time
3. Use expired token
4. Verify rejection

Expected Results:

• 401 Unauthorized
• Error: "Token expired"
• Automatic refresh triggered (if refreshToken valid)

TC-SEC-AUTH-004: Brute Force Protection

Priority: P1 (High)

Test Steps:

1. Attempt login with wrong password 5 times
2. Verify account locked or rate limited
3. Check cooldown period

Expected Results:

• After 5 failed attempts: Account temporarily locked
• Lockout duration: 15 minutes
• User notified via email (optional)
• Subsequent attempts rejected with 429 status

Implementation:

// Rate limiting configuration
{
  maxAttempts: 5,
  windowMs: 15 * 60 * 1000, // 15 minutes
  message: "Too many login attempts. Please try again later."
}

TC-SEC-AUTH-005: Password Storage Security

Priority: P0 (Critical)

Test Steps:

1. Create account with password
2. Access database directly
3. Verify password hashed
4. Check hash algorithm

Expected Results:

• Password NOT stored in plaintext
• Bcrypt/Argon2 hashing used
• Salt included in hash
• Hash format: $2a$10$... (bcrypt) or similar

3.2 Credit System Security Tests

TC-SEC-CREDIT-001: Credit Balance Tampering

Priority: P0 (Critical)

Test Steps:

1. Attempt to modify credit balance via API manipulation
2. Send crafted requests with inflated balance
3. Directly modify client-side storage
4. Verify all attempts fail

Expected Results:

• Server-side validation rejects all tampering
• Balance only modifiable via authorized endpoints
• JWT claims for credits are read-only
• Client-side changes overwritten by server

TC-SEC-CREDIT-002: Unauthorized Credit Deduction

Priority: P0 (Critical)

Test Steps:

1. User A attempts to deduct credits from User B
2. Forge JWT with different user ID
3. Attempt API calls with manipulated token

Expected Results:

• All attempts fail with 401/403
• User B's credits unchanged
• Audit log records suspicious activity

TC-SEC-CREDIT-003: Replay Attack Prevention

Priority: P1 (High)

Test Steps:

1. Capture valid credit purchase webhook
2. Replay webhook multiple times
3. Verify duplicate detection

Expected Results:

• Only first webhook processed
• Duplicates detected by transaction ID
• No double-crediting

3.3 Rate Limiting Tests

TC-SEC-RATE-001: API Rate Limiting

Priority: P1 (High)

Test Steps:

1. Make 100 API requests in 1 minute
2. Verify rate limit enforced
3. Check error response

Expected Results:

• Rate limit: 100 requests/minute per user
• After limit: 429 Too Many Requests
• Retry-After header provided
• Limit resets after window

Rate Limit Configuration:

{
  '/auth/signin': { max: 10, window: '1m' },
  '/auth/refresh': { max: 20, window: '1m' },
  '/api/*': { max: 100, window: '1m' }
}

TC-SEC-RATE-002: Credit Operation Rate Limiting

Priority: P2 (Medium)

Test Steps:

1. Perform 50 credit-consuming operations rapidly
2. Verify rate limiting or throttling
3. Check if legitimate operations still work

Expected Results:

• Suspicious rapid operations flagged
• Possible CAPTCHA or verification required
• Normal user activity not impacted

---

4. Integration Testing

4.1 Mobile App Integration Tests

TC-INT-MOBILE-001: iOS App Authentication Flow

Priority: P0 (Critical)

Test Steps:

1. Install iOS app (Memoro)
2. Register new account
3. Verify token storage in SecureStore
4. Close and reopen app
5. Check session persistence
6. Make API call requiring authentication

Expected Results:

• Registration succeeds
• Tokens stored in iOS Keychain via SecureStore
• App reopens with user still authenticated
• API calls succeed with valid token

Platform-Specific Checks:

• SecureStore API usage
• Background token refresh handling
• App backgrounding behavior

TC-INT-MOBILE-002: Android App Authentication Flow

Priority: P0 (Critical)

Test Steps:

1. Install Android app (Memoro)
2. Register new account
3. Verify token storage in SecureStore
4. Close and reopen app
5. Check session persistence

Expected Results:

• Similar to iOS
• Tokens stored in Android Keystore via SecureStore
• Handle Android-specific lifecycle events

TC-INT-MOBILE-003: React Native Token Refresh

Priority: P0 (Critical)

Test Steps:

1. Login on mobile app
2. Wait for token expiry
3. Make API call
4. Verify automatic refresh
5. Check UI remains responsive

Expected Results:

• Refresh handled by TokenManager
• UI shows loading indicator
• API call succeeds after refresh
• User unaware of background process

4.2 Web App Integration Tests

TC-INT-WEB-001: SvelteKit Authentication (Memoro Web)

Priority: P0 (Critical)

Test Steps:

1. Open web app in browser
2. Register account
3. Verify tokens in localStorage
4. Refresh browser page
5. Check session restored

Expected Results:

• Tokens stored in localStorage
• Page refresh maintains authentication
• SSR (server-side rendering) respects auth state
• Protected routes accessible

TC-INT-WEB-002: Cross-Browser Compatibility

Priority: P1 (High)

Test Steps:

1. Test authentication in Chrome, Safari, Firefox, Edge
2. Verify consistent behavior
3. Check localStorage access
4. Test token refresh

Expected Results:

• All browsers work identically
• No storage access issues
• Token refresh works across all browsers

4.3 Cross-App Integration Tests

TC-INT-CROSS-001: Memoro to Maerchenzauber Auth

Priority: P0 (Critical)

Test Steps:

1. Login to Memoro app
2. Open Maerchenzauber app (same device/browser)
3. Verify authentication state
4. Check credit balance visibility

Expected Results:

• User authenticated in both apps (if SSO enabled)
• OR: Separate login required but same user account recognized
• Credit balance synchronized
• app_id claim in JWT differentiates apps

TC-INT-CROSS-002: Multi-App Credit Consumption

Priority: P0 (Critical)

Test Steps:

1. User has 100 credits
2. Consume 30 credits in Memoro (AI transcription)
3. Immediately check balance in Maerchenzauber
4. Consume 20 credits in Maerchenzauber (story generation)
5. Check final balance in both apps

Expected Results:

• Memoro: Balance updates to 70 credits
• Maerchenzauber: Shows 70 credits
• Second operation: Balance updates to 50
• Both apps show final balance: 50 credits
• Real-time sync (< 1 second delay)

4.4 Payment Gateway Integration Tests

TC-INT-PAYMENT-001: RevenueCat Purchase Flow (iOS)

Priority: P0 (Critical)

Test Steps:

1. Login to Memoro iOS app
2. Navigate to subscription page
3. Purchase 100 credits
4. Complete Apple Pay transaction
5. Verify webhook received
6. Check credit balance updated

Expected Results:

• RevenueCat processes purchase
• Webhook sent to backend
• Credits added to user account
• User sees updated balance
• Receipt validated

RevenueCat Specifics:

• User identified with UUID
• StoreKit 2 integration on iOS
• Purchase restoration works across devices

TC-INT-PAYMENT-002: RevenueCat Purchase Flow (Android)

Priority: P0 (Critical)

Test Steps:

1. Login to Memoro Android app
2. Purchase credits
3. Complete Google Play transaction
4. Verify webhook and credit update

Expected Results:

• Similar to iOS
• Google Play Billing integration
• Webhook processing

TC-INT-PAYMENT-003: RevenueCat Purchase Flow (Web)

Priority: P1 (High)

Test Steps:

1. Login to Memoro web app
2. Purchase credits (Stripe or other web payment)
3. Complete payment
4. Verify webhook and credit update

Expected Results:

• Payment processed via Stripe
• Webhook processed
• Credits updated

4.5 Backend Service Integration Tests

TC-INT-BACKEND-001: NestJS Backend Auth Flow (Maerchenzauber)

Priority: P0 (Critical)

Test Steps:

1. Mobile app sends login request
2. Backend validates with middleware
3. Backend returns tokens
4. Backend validates subsequent API calls with JWT

Expected Results:

• Backend acts as auth proxy
• Supabase RLS policies enforced
• JWT claims validated on every request
• Invalid tokens rejected with 401

TC-INT-BACKEND-002: Credit Deduction in Backend Pipeline

Priority: P0 (Critical)

Test Steps:

1. User requests story creation (Maerchenzauber backend)
2. Backend validates credits via Mana Core
3. Story generated
4. Backend consumes credits
5. Check transaction logged

Expected Results:

• Credit validation before operation
• Operation executes only if credits available
• Credits deducted after success
• Rollback if operation fails

Code Reference:

// See: maerchenzauber/apps/backend/src/pipeline/character/steps/deduct-credits.step.ts

---

5. Performance Testing

5.1 Load Testing

TC-PERF-LOAD-001: Concurrent User Logins

Priority: P1 (High)

Test Configuration:

• Virtual Users: 1000
• Ramp-up: 10 seconds
• Duration: 5 minutes

Test Steps:

1. Simulate 1000 users logging in concurrently
2. Measure response times
3. Check success rate
4. Monitor server resources

Expected Results:

• 95% of requests complete in < 2 seconds
• 99% of requests complete in < 5 seconds
• Success rate: > 99%
• No server crashes or timeouts
• CPU usage < 80%
• Memory usage stable

Performance Metrics:

Concurrent Users: 1000
Avg Response Time: < 500ms
P95 Response Time: < 2s
P99 Response Time: < 5s
Error Rate: < 1%

TC-PERF-LOAD-002: Token Refresh Under Load

Priority: P1 (High)

Test Configuration:

• Virtual Users: 500
• Simultaneous expired tokens: 500
• Duration: 2 minutes

Test Steps:

1. 500 users with expired tokens make API calls
2. Measure refresh endpoint performance
3. Check queue handling
4. Verify no duplicate refreshes

Expected Results:

• Refresh endpoint handles 500 concurrent requests
• Token manager queue processes efficiently
• Avg response time: < 1 second
• No request timeouts
• All users successfully refreshed

TC-PERF-LOAD-003: Credit Balance Checks at Scale

Priority: P1 (High)

Test Configuration:

• Virtual Users: 2000
• Requests/second: 100
• Duration: 10 minutes

Test Steps:

1. 2000 users checking credit balance simultaneously
2. Measure database query performance
3. Check caching effectiveness

Expected Results:

• Query time: < 50ms
• Database connection pool stable
• Caching reduces database load
• No connection exhaustion

5.2 Stress Testing

TC-PERF-STRESS-001: Credit Deduction Stress Test

Priority: P1 (High)

Test Configuration:

• Virtual Users: 100
• Operations per user: 50
• Total operations: 5000

Test Steps:

1. 100 users each perform 50 credit-consuming operations
2. Measure transaction throughput
3. Check for race conditions or double-deductions
4. Verify all balances correct

Expected Results:

• All 5000 operations complete successfully
• No over-deductions or under-deductions
• Database transactions maintain consistency
• Final balances reconcile with transaction logs

TC-PERF-STRESS-002: Payment Webhook Storm

Priority: P2 (Medium)

Test Configuration:

• Concurrent webhooks: 1000
• Duplicate percentage: 20%

Test Steps:

1. Send 1000 webhook notifications rapidly
2. Include 200 duplicate webhooks
3. Measure processing time
4. Verify idempotency

Expected Results:

• All unique webhooks processed
• Duplicates detected and ignored
• No double-crediting
• Processing time: < 5 seconds for all
• Database remains consistent

5.3 Scalability Testing

TC-PERF-SCALE-001: Database Scaling - Credit Transactions

Priority: P2 (Medium)

Test Scenario:

• Simulate 1 million credit transactions over 24 hours
• Monitor database growth
• Check query performance degradation

Expected Results:

• Database handles high transaction volume
• Indexes maintain query performance
• No significant slowdown over time
• Automated cleanup/archiving if needed

---

6. Acceptance Criteria

6.1 Authentication System Acceptance

AC-AUTH-001: User can register with email/password in < 3 seconds AC-AUTH-002: User can login with email/password in < 2 seconds AC-AUTH-003: Token refresh happens automatically without user interaction AC-AUTH-004: User remains logged in for 30 days (refreshToken lifetime) AC-AUTH-005: Password reset email arrives within 5 minutes AC-AUTH-006: Multi-device login works for up to 5 devices simultaneously AC-AUTH-007: 99.9% uptime for authentication services

6.2 Credit System Acceptance

AC-CREDIT-001: Credit balance updates within 1 second of purchase AC-CREDIT-002: Credit deduction happens only after operation succeeds AC-CREDIT-003: Failed operations never charge credits AC-CREDIT-004: Credit balance visible across all apps within 1 second AC-CREDIT-005: Transaction history available for 24 months AC-CREDIT-006: No race conditions allow negative balance AC-CREDIT-007: Refunds processed within 1 hour (automated)

6.3 Integration Acceptance

AC-INT-001: Mobile apps support iOS 14+ and Android 10+ AC-INT-002: Web apps work on Chrome, Safari, Firefox, Edge (latest 2 versions) AC-INT-003: RevenueCat purchase flow completes in < 30 seconds AC-INT-004: Backend API response time < 500ms for 95% of requests AC-INT-005: Cross-app authentication works seamlessly

6.4 Security Acceptance

AC-SEC-001: No plaintext passwords stored anywhere AC-SEC-002: JWT tokens secured with RS256 algorithm AC-SEC-003: Rate limiting prevents brute force attacks AC-SEC-004: SQL injection attempts blocked 100% AC-SEC-005: XSS vulnerabilities: 0 critical, 0 high AC-SEC-006: Penetration test: No critical vulnerabilities

6.5 Performance Acceptance

AC-PERF-001: System handles 1000 concurrent users without degradation AC-PERF-002: 99th percentile response time < 3 seconds AC-PERF-003: Token refresh completes in < 2 seconds AC-PERF-004: Credit balance check < 100ms AC-PERF-005: Database can scale to 10 million users

---

7. Regression Testing

7.1 Regression Test Suite

RT-001: Core Authentication Flows

• Run after every auth system change
• Includes: Login, registration, logout, refresh

RT-002: Credit Balance & Consumption

• Run after every credit system change
• Includes: Purchase, deduction, balance check

RT-003: Multi-App Integration

• Run after any app deployment
• Includes: Cross-app auth, credit sync

RT-004: Security Regression

• Run monthly or after security patches
• Includes: All security test cases

7.2 Automated Regression Schedule

Daily:
  - Smoke tests (critical paths)
  - Core auth flows
  - Credit balance checks

Weekly:
  - Full regression suite
  - Integration tests
  - Performance smoke tests

Monthly:
  - Full security audit
  - Load testing
  - Penetration testing

After Each Deployment:
  - Smoke tests (5 minutes)
  - Core regression (30 minutes)
  - Integration verification (15 minutes)

---

8. Test Environments

8.1 Environment Configuration

Development Environment

• Purpose: Developer testing
• Database: Supabase dev project
• Middleware: Local middleware instance
• Payment: Mock payment gateway (no real charges)
• Data: Test user accounts, synthetic credit data

Staging Environment

• Purpose: Pre-production testing, QA validation
• Database: Supabase staging project (copy of production schema)
• Middleware: Staging middleware instance
• Payment: RevenueCat sandbox mode
• Data: Anonymized production data sample

Production Environment

• Purpose: Live user traffic
• Database: Supabase production project
• Middleware: Production middleware cluster
• Payment: RevenueCat production mode (real charges)
• Data: Live user data (protected by RLS)

8.2 Test Data Management

Test Users:

{
  testUser1: { email: "test+user1@manacore.com", password: "Test123!@#", credits: 1000 },
  testUser2: { email: "test+user2@manacore.com", password: "Test123!@#", credits: 0 },
  testUserB2B: { email: "test+b2b@manacore.com", password: "Test123!@#", b2b: true }
}

Test Credit Packages:

{
  small: { credits: 100, price: 4.99 },
  medium: { credits: 500, price: 19.99 },
  large: { credits: 1000, price: 34.99 }
}

---

9. Test Automation Strategy

9.1 Unit Tests

Coverage Target: 80% minimum

Framework: Jest

Test Files:

• packages/shared-auth/src/**/*.test.ts
• packages/shared-credit-service/src/**/*.test.ts

Example:

describe('AuthService', () => {
  it('should sign in with valid credentials', async () => {
    const result = await authService.signIn('test@example.com', 'password');
    expect(result.success).toBe(true);
  });
});

9.2 Integration Tests

Coverage Target: Critical paths 100%

Framework: Jest + Supertest (for API tests)

Test Files:

• maerchenzauber/apps/backend/test/*.test.ts
• memoro/apps/mobile/features/auth/__tests__/*.test.ts

Example:

describe('Credit Purchase Flow', () => {
  it('should add credits after successful payment', async () => {
    const response = await request(app)
      .post('/webhooks/revenuecat')
      .send(mockWebhookPayload);

    expect(response.status).toBe(200);
    const balance = await getCredits(userId);
    expect(balance).toBe(previousBalance + 100);
  });
});

9.3 E2E Tests

Coverage Target: User journeys 100%

Framework: Detox (mobile), Playwright (web)

Test Files:

• memoro/apps/mobile/e2e/*.e2e.ts
• memoro/apps/web/tests/*.spec.ts

Example:

describe('User Registration Journey', () => {
  it('should register, login, and access protected content', async () => {
    await element(by.id('register-button')).tap();
    await element(by.id('email-input')).typeText('new@example.com');
    await element(by.id('password-input')).typeText('SecureP@ss123');
    await element(by.id('submit-button')).tap();

    await waitFor(element(by.id('home-screen'))).toBeVisible().withTimeout(5000);
    expect(element(by.id('credit-balance'))).toBeVisible();
  });
});

9.4 Performance Tests

Framework: k6

Test Files:

• tests/performance/auth-load.js
• tests/performance/credit-stress.js

Example:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 1000 },
    { duration: '2m', target: 0 },
  ],
};

export default function () {
  const res = http.post('https://api.manacore.com/auth/signin', {
    email: 'test@example.com',
    password: 'password',
  });

  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1);
}

9.5 CI/CD Integration

Pipeline Stages:

1. Pre-commit: Lint, unit tests (local)
2. Pull Request: Unit tests, integration tests, security scan
3. Staging Deploy: Full regression suite, performance smoke tests
4. Production Deploy: Smoke tests, monitoring alert setup

GitHub Actions Example:

name: Test & Deploy

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: pnpm install
      - run: pnpm run test:unit
      - run: pnpm run test:integration
      - run: pnpm run test:e2e

  performance:
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v3
      - run: k6 run tests/performance/auth-load.js

---

10. Compliance & Audit

10.1 Payment Compliance Testing

PCI DSS Requirements:

• TC-COMP-PCI-001: No credit card data stored locally
• TC-COMP-PCI-002: Payment processed via certified gateway (RevenueCat)
• TC-COMP-PCI-003: Secure transmission (HTTPS only)

10.2 GDPR Compliance Testing

Data Privacy:

• TC-COMP-GDPR-001: User can delete account and all data
• TC-COMP-GDPR-002: User can export all personal data
• TC-COMP-GDPR-003: Consent for data processing obtained

10.3 Audit Logging

Requirements:

• All credit transactions logged with timestamp, user, amount, operation
• All authentication events logged (login, logout, refresh)
• Logs retained for 12 months minimum
• Logs tamper-proof and auditable

Test Cases:

• TC-AUDIT-001: Verify credit transaction log completeness
• TC-AUDIT-002: Verify auth event log accuracy
• TC-AUDIT-003: Test log export functionality

---

11. Risk Mitigation

11.1 High-Risk Scenarios

Risk: Credit double-deduction due to race condition Mitigation: Database transactions, optimistic locking Test: TC-CREDIT-CONSUME-003

Risk: Token hijacking/replay attacks Mitigation: Short token lifetime, HTTPS only, refresh rotation Test: TC-SEC-AUTH-002, TC-SEC-CREDIT-003

Risk: Payment webhook failure (credits not added) Mitigation: Webhook retry mechanism, idempotency keys, manual reconciliation Test: TC-CREDIT-PURCHASE-004

Risk: Concurrent login causing session conflicts Mitigation: Independent refresh tokens per device Test: TC-AUTH-SESSION-001

11.2 Disaster Recovery Testing

Scenario: Database failure during credit purchase Test: Verify rollback mechanism, no lost credits Recovery Time Objective (RTO): < 1 hour Recovery Point Objective (RPO): < 5 minutes

Scenario: Middleware authentication service down Test: Graceful degradation, cached credentials, retry logic RTO: < 15 minutes (failover to backup)

---

12. Test Execution Schedule

12.1 Sprint Testing

Week 1-2 (Development):

• Unit tests written alongside features
• Developer-run integration tests
• Daily: Smoke tests

Week 3 (QA Testing):

• Full manual test execution
• Automated regression suite
• Performance baseline tests
• Security scan

Week 4 (Pre-Release):

• Staging environment validation
• User acceptance testing (UAT)
• Load testing
• Final security check

12.2 Release Testing

Pre-Deployment:

• Run full regression suite
• Performance smoke test
• Security scan
• Backup verification

Post-Deployment:

• Smoke tests (5 minutes)
• Monitoring validation (15 minutes)
• Canary deployment testing (1 hour)

---

13. Tools & Resources

13.1 Testing Tools

Unit & Integration:

• Jest (JavaScript testing framework)
• Supertest (HTTP API testing)
• React Native Testing Library

E2E:

• Detox (React Native E2E)
• Playwright (Web E2E)
• Appium (mobile alternative)

Performance:

• k6 (load testing)
• Lighthouse (web performance)
• New Relic (production monitoring)

Security:

• OWASP ZAP (security scanner)
• Snyk (dependency vulnerability scanning)
• SonarQube (code quality & security)

13.2 Test Management

Test Case Repository: GitHub Wiki or Notion Bug Tracking: GitHub Issues with labels (bug, critical, security) Test Execution: Manual execution logged in test management tool CI/CD: GitHub Actions

13.3 Documentation

For Developers:

• maerchenzauber/apps/mobile/AUTH_TESTING_GUIDE.md
• packages/shared-auth/README.md
• manadeck/CREDIT_SYSTEM.md

For QA:

• This document (TESTING_STRATEGY_AUTH_CREDITS.md)
• Test case templates in tests/templates/

---

14. Appendix

A. Test Case Template

#### TC-[CATEGORY]-[MODULE]-[ID]: [Test Name]
**Priority:** P0/P1/P2
**Description:** [Brief description]

**Preconditions:**
- [Setup required]

**Test Steps:**
1. [Step 1]
2. [Step 2]
...

**Expected Results:**
- [Expected outcome 1]
- [Expected outcome 2]

**Test Data:**
[Data needed for test]

**Post-Conditions:**
- [Cleanup steps]

B. Bug Report Template

**Title:** [Brief description]
**Severity:** Critical / High / Medium / Low
**Environment:** Dev / Staging / Production
**Device/Browser:** [Details]

**Steps to Reproduce:**
1. [Step 1]
2. [Step 2]

**Expected Behavior:**
[What should happen]

**Actual Behavior:**
[What actually happens]

**Screenshots/Logs:**
[Attach evidence]

**Related Test Case:** TC-XXX-XXX-XXX

C. Glossary

appToken: Supabase-compatible JWT token for API access refreshToken: Long-lived token for obtaining new appToken manaToken: Authentication token from Mana Core middleware RLS: Row Level Security (Supabase database security) JWT: JSON Web Token SecureStore: Expo secure storage API (Keychain on iOS, Keystore on Android) TokenManager: Service managing token lifecycle and refresh RevenueCat: Third-party subscription and payment management platform B2B: Business-to-Business (enterprise accounts)

---

Document Control

Version History:

Version	Date	Author	Changes
1.0	2025-11-25	TESTER Agent	Initial comprehensive test strategy

Review & Approval:

• Technical Lead Review
• QA Lead Review
• Security Team Review
• Product Owner Approval

Next Review Date: 2025-12-25

---

END OF DOCUMENT