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
// 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
// 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
)
- 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:
# 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:
# 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:
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:
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
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:
- Follow naming conventions:
test_[component]_[functionality].rs
- Add documentation: Explain what the test does and why
- Include in this README: Update this guide with new test categories
- Test the test: Ensure your test can detect both success and failure conditions
Troubleshooting
Common Issues
- Compilation Errors: Ensure all required dependencies are available
- Test Failures: Check that test data matches expected formats
- Permission Issues: Verify file system permissions for data files
- Concurrency Issues: Ensure tests don't interfere with each other
Getting Help
- Check the main
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.