Testing Fixtures
Validate auth, billing, onboarding, and protected SaaS states locally with production-shaped testing fixtures.
Production-shaped local testingLink to section
Starter Pro includes seeded account states designed to validate realistic SaaS behavior during development.
The goal is not only to create users.
The goal is to simulate:
- authentication states
- onboarding states
- billing states
- protected route behavior
- subscription-aware product access
Validate realistic SaaS states locally.
One-time payment · Instant access after purchase
Core principle
Serious SaaS products require realistic account states during development.
Why this existsLink to section
Most SaaS products become difficult to validate locally because developers must manually recreate account edge cases repeatedly.
Starter Pro reduces that friction by exposing reusable testing states.
Seed fixtures
↓
Account states
↓
Billing states
↓
Protected routes
↓
Realistic product validationWhy account states matterLink to section
Real SaaS products behave differently depending on:
- verification lifecycle
- billing status
- provider state
- onboarding state
- protected access level
Without realistic fixtures, developers often validate only happy paths.
That creates hidden production risk later.
Production insight
A single happy-path user is not enough to validate a SaaS product. Real products require multiple identity, billing, and access states.
Mental modelLink to section
Identity state
Identity state determines whether a user is verified, OAuth-only, password-based, or ready for normal product access.
Feature overviewLink to section
Authentication testing
Billing validation
Onboarding states
Product confidence
Enable fixturesLink to section
SEED_AUTH_FIXTURES=trueThen run:
pnpm app:setupIncluded testing statesLink to section
Standard user
- protected routes
- dashboard navigation
- authenticated settings
- normal SaaS usage
Unverified user
- email verification
- restricted access
- verification prompts
- onboarding edge cases
Provider-only user
- Google sign in
- GitHub sign in
- provider linking
- OAuth-only restrictions
Subscription-enabled user
- premium routes
- upgrade flows
- billing access
- plan-aware UI
Seeded accountsLink to section
When SEED_AUTH_FIXTURES=true, Starter Pro creates multiple local testing accounts designed to validate realistic SaaS behavior.
Included accountsLink to section
| Account | Password | State | Use case |
|---|---|---|---|
free@pycolors.io | Password123! | Verified free user | Validate normal authenticated product behavior without PRO access |
unverified@pycolors.io | Password123! | Unverified user | Validate email verification and restricted onboarding flows |
oauth@pycolors.io | No password | OAuth-only user | Validate provider-linked accounts and add-password flows |
pro@pycolors.io | Password123! | Verified PRO trialing user | Validate premium access, billing-aware navigation, and subscription-gated product behavior |
Local-only fixtures
These accounts are development fixtures intended only for local and controlled staging environments. Never reuse these credentials in production systems.
Default credentialsLink to section
Password123!These credentials are intended only for local development environments.
Security rule
Never reuse development credentials in staging or production environments.
Recommended validation flowLink to section
Enable fixture seedingLink to section
Set SEED_AUTH_FIXTURES=true in your local environment.
Run setupLink to section
pnpm app:setupValidate authentication statesLink to section
Test verified, unverified, password-based, and OAuth-oriented account behavior.
Validate billing-aware statesLink to section
Confirm that premium, free, and upgrade-gated surfaces behave as expected.
Validate mobile and PWA behaviorLink to section
Confirm that the same account states remain usable in mobile and standalone app contexts.
Common mistakesLink to section
Testing only happy paths
Hardcoded product access
Fixture leakage
Desktop-only validation
Prefer / avoidLink to section
Prefer
- validate multiple account states
- test billing-aware product behavior
- keep fixtures isolated to development
- test OAuth and credentials flows
- validate mobile and PWA behavior
Avoid
- hardcoding product access
- testing only one account state
- using development credentials in production
- coupling fixtures to business logic
- skipping restricted account states