init projectmycelium

2025-09-01 21:37:01 -04:00
commit b41efb0e99
319 changed files with 128160 additions and 0 deletions
--- a/tests/tests_archive/README.md
+++ b/tests/tests_archive/README.md
@@ -0,0 +1,257 @@
+# Project Mycelium Testing Guide
+
+This directory contains tests for the Project Mycelium application. This guide explains how to write and run tests for various marketplace components.
+
+## Test Structure
+
+### Directory Layout
+```
+tests/
+├── README.md              # This guide
+├── test_tfp_fix.rs       # TFP purchase data preservation test
+└── [future test files]   # Additional tests as needed
+```
+
+## Types of Tests
+
+### 1. Unit Tests
+Test individual functions and components in isolation.
+
+**Example: Testing Currency Conversion**
+```rust
+// tests/test_currency.rs
+fn main() {
+    println!("=== Currency Conversion Test ===");
+    
+    let base_amount = 100.0;
+    let conversion_rate = 0.1; // 1 TFP = 0.1 USD
+    let expected_usd = base_amount * conversion_rate;
+    
+    println!("Converting {} TFP to USD", base_amount);
+    println!("Expected: ${}", expected_usd);
+    
+    // Test logic here
+    assert_eq!(expected_usd, 10.0);
+    println!("✅ Currency conversion test passed!");
+}
+```
+
+### 2. Integration Tests
+Test how different components work together.
+
+**Example: Testing User Data Persistence**
+```rust
+// tests/test_user_persistence.rs
+fn main() {
+    println!("=== User Data Persistence Test ===");
+    
+    // Simulate user data operations
+    let user_email = "test@example.com";
+    let initial_balance = 1000.0;
+    let services_count = 3;
+    
+    // Test data preservation during operations
+    println!("Testing data persistence for user: {}", user_email);
+    println!("Initial balance: {}", initial_balance);
+    println!("Services count: {}", services_count);
+    
+    // Verify data integrity
+    println!("✅ User data persistence test passed!");
+}
+```
+
+### 3. Bug Fix Verification Tests
+Test specific bug fixes to ensure they work correctly.
+
+**Example: TFP Purchase Fix Test** (see [`test_tfp_fix.rs`](test_tfp_fix.rs))
+- Tests that TFP purchases preserve existing user data
+- Verifies wallet balance updates correctly
+- Ensures services, apps, and profile data are not lost
+
+## Running Tests
+
+### Simple Rust Tests
+For standalone test files without external dependencies:
+
+```bash
+# Compile and run a specific test
+rustc tests/test_name.rs && ./test_name
+
+# Example: Run TFP fix test
+rustc tests/test_tfp_fix.rs && ./test_tfp_fix
+```
+
+### Cargo Tests
+For tests that need access to the main crate:
+
+```bash
+# Run all tests
+cargo test
+
+# Run specific test
+cargo test test_name
+
+# Run tests with output
+cargo test -- --nocapture
+```
+
+## Writing Effective Tests
+
+### 1. Test Structure
+Follow the **Arrange-Act-Assert** pattern:
+
+```rust
+fn test_example() {
+    // ARRANGE: Set up test data
+    let initial_data = setup_test_data();
+    
+    // ACT: Perform the operation being tested
+    let result = perform_operation(initial_data);
+    
+    // ASSERT: Verify the results
+    assert_eq!(result.status, "success");
+    println!("✅ Test passed!");
+}
+```
+
+### 2. Test Categories
+
+#### Data Integrity Tests
+- Verify data is preserved during operations
+- Test backup and recovery mechanisms
+- Ensure no data loss during updates
+
+#### Business Logic Tests
+- Test marketplace transactions
+- Verify pricing calculations
+- Test user role permissions
+
+#### API Endpoint Tests
+- Test HTTP request/response handling
+- Verify authentication and authorization
+- Test error handling and edge cases
+
+#### Performance Tests
+- Test response times under load
+- Verify memory usage patterns
+- Test concurrent user scenarios
+
+### 3. Test Data Management
+
+#### Mock Data
+Use consistent test data across tests:
+
+```rust
+fn create_test_user() -> TestUser {
+    TestUser {
+        email: "test@example.com".to_string(),
+        balance: 1000.0,
+        services: vec!["Service 1".to_string(), "Service 2".to_string()],
+        apps: vec!["App 1".to_string()],
+    }
+}
+```
+
+#### Test Isolation
+Ensure tests don't interfere with each other:
+- Use unique test data for each test
+- Clean up after tests when necessary
+- Avoid shared mutable state
+
+## Marketplace-Specific Testing
+
+### 1. User Management Tests
+- User registration and authentication
+- Profile updates and data persistence
+- Account deletion and recovery
+
+### 2. Wallet and Transaction Tests
+- TFP purchases and sales
+- Balance updates and transaction history
+- Currency conversion accuracy
+
+### 3. Service Provider Tests
+- Service creation and management
+- SLA compliance and monitoring
+- Revenue tracking and reporting
+
+### 4. App Provider Tests
+- App deployment and management
+- Health monitoring and auto-healing
+- Resource utilization tracking
+
+### 5. Marketplace Operations Tests
+- Product search and filtering
+- Shopping cart functionality
+- Order processing and fulfillment
+
+## Best Practices
+
+### 1. Test Naming
+Use descriptive names that explain what is being tested:
+- `test_tfp_purchase_preserves_user_data`
+- `test_currency_conversion_accuracy`
+- `test_service_creation_validation`
+
+### 2. Error Testing
+Always test error conditions:
+- Invalid input data
+- Network failures
+- Database connection issues
+- Authentication failures
+
+### 3. Edge Cases
+Test boundary conditions:
+- Zero amounts and empty data
+- Maximum limits and constraints
+- Concurrent operations
+- System resource limits
+
+### 4. Documentation
+Document complex test scenarios:
+- Explain the business logic being tested
+- Describe the expected behavior
+- Note any special setup requirements
+
+## Example Test Scenarios
+
+### Scenario 1: TFP Purchase Data Preservation
+**Problem**: TFP purchases were removing all other user data
+**Test**: Verify that after a TFP purchase, all existing user data (services, apps, profile) is preserved
+**File**: [`test_tfp_fix.rs`](test_tfp_fix.rs)
+
+### Scenario 2: Service Provider Revenue Tracking
+**Test**: Verify that service provider revenue is calculated correctly across multiple clients
+**Expected**: Revenue should accumulate properly without data loss
+
+### Scenario 3: App Auto-Healing Functionality
+**Test**: Verify that apps with auto-healing enabled recover from simulated failures
+**Expected**: Health scores should improve after recovery
+
+## Contributing Tests
+
+When adding new tests:
+
+1. **Follow naming conventions**: `test_[component]_[functionality].rs`
+2. **Add documentation**: Explain what the test does and why
+3. **Include in this README**: Update this guide with new test categories
+4. **Test the test**: Ensure your test can detect both success and failure conditions
+
+## Troubleshooting
+
+### Common Issues
+
+1. **Compilation Errors**: Ensure all required dependencies are available
+2. **Test Failures**: Check that test data matches expected formats
+3. **Permission Issues**: Verify file system permissions for data files
+4. **Concurrency Issues**: Ensure tests don't interfere with each other
+
+### Getting Help
+
+- Check the main [`MARKETPLACE_ARCHITECTURE.md`](../MARKETPLACE_ARCHITECTURE.md) for system overview
+- Review existing tests for patterns and examples
+- Consult the Rust testing documentation for advanced features
+
+---
+
+**Remember**: Good tests are an investment in code quality and system reliability. They help catch bugs early and provide confidence when making changes to the marketplace codebase.