projectmycelium/tests/tests_archive/README.md

# 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.