Self-Testing Strategies for FE

Nowadays some modern projects lack dedicated QA engineers, so developers must invest more time and thoughtful strategies in self-testing to maintain code quality. This article shares practical self-testing approaches to reduce bugs and mental stress.

1. Local Environment Testing

(1) Black-Box Testing

1. Cover User Interaction Combinations
   
   • Test permutations of user workflows (especially in complex modules)
   
   • Time-constrained priority: Focus on critical paths first

2. Edge Case Testing (Optional based on quality requirements)
   
   • Extreme data: Overlong text, huge numbers, special characters
   
   • Error scenarios: Network disruption, API timeouts, permission changes

(2) White-Box Code Validation

1. Impact Analysis
   
   • Global config changes: Trace affected areas
   
   • Component/method updates: Use Find References (VS Code) to audit call cases

2. Mindset Warning ⚠️
   
   • Treat code change cautiously even if you're the sole developer

2. Automated Mock Data Detection

Problem: Local environments often lack realistic API responses, forcing developers to use mock data that might accidentally reach production.

Solution:

1. Mark mock data with mockXX prefix (e.g., mockUserData)
2. Implement pre-commit hook validation(Stay tuned! Article coming soon.)

3. Post-Deployment Verification

Critical Checks:

• Re-test affected modules using real production data

• Identify environment-specific differences in your system

Frontend-Specific Tip:

Real data often reveals issues invisible in local mocks - e.g.,

// Local mock  
{ value: 100, label: 'Test' }  
// Production data  
{ value: 24583, label: 'Ultra-long-category-name-needs-truncation' }  

Why This Matters

Implementing these strategies helps:

✅ Reduce regression bugs

✅ Minimize "bug politics" (using defects as criticism leverage)

✅ Lower mental fatigue from deployment anxiety

Remember: Your well-being matters as much as code quality. A systematic testing approach protects both! ❤️