CaddyManager/CaddyManager.Tests/README.md

# CaddyManager Tests

This project contains comprehensive unit tests for the CaddyManager application.

## Test Structure

The tests are organized to mirror the main project structure:

### Services Tests
- **CaddyConfigurationParsingService**: Tests for parsing Caddyfile content and extracting hostnames, reverse proxy targets, and ports
- **CaddyService**: Tests for managing Caddy configuration files (CRUD operations)
- **ConfigurationsService**: Tests for configuration management and dependency injection
- **DockerService**: Tests for Docker container management functionality

### Models Tests
- **CaddyConfigurationInfo**: Tests for configuration information model
- **CaddyOperationResponse**: Tests for operation response model
- **CaddyDeleteOperationResponse**: Tests for delete operation response model
- **CaddySaveConfigurationRequest**: Tests for save configuration request model

### Configuration Tests
- **CaddyServiceConfigurations**: Tests for Caddy service configuration class
- **DockerServiceConfiguration**: Tests for Docker service configuration class

### Test Utilities
- **TestHelper**: Common utilities for creating test data, temporary files, and configurations

## Running Tests

### Run all tests
```bash
dotnet test
```

### Run tests with coverage
```bash
dotnet test --collect:"XPlat Code Coverage" --settings coverlet.runsettings
```

### Run specific test class
```bash
dotnet test --filter "ClassName=CaddyServiceTests"
```

### Run tests with verbose output
```bash
dotnet test --verbosity normal
```

## Test Coverage

The project is configured to generate code coverage reports in multiple formats:
- OpenCover
- Cobertura
- JSON
- LCOV
- TeamCity
- HTML

Coverage reports exclude:
- Test projects (`[*.Tests]*`)
- Program entry points (`[*]*.Program`)
- Migration files (`[*]*Migrations*`)
- Generated code (marked with appropriate attributes)

## Test Frameworks and Libraries

- **xUnit**: Primary testing framework
- **AwesomeAssertions**: For readable assertions
- **Moq**: For mocking dependencies
- **Coverlet**: For code coverage analysis

## Test Patterns

The tests follow these patterns:

### Arrange-Act-Assert (AAA)
All tests use the AAA pattern for clarity:
```csharp
[Fact]
public void Method_Condition_ExpectedResult()
{
    // Arrange
    var input = "test input";
    
    // Act
    var result = service.Method(input);
    
    // Assert
    result.Should().Be("expected output");
}
```

### Theory Tests
For testing multiple scenarios:
```csharp
[Theory]
[InlineData("input1", "output1")]
[InlineData("input2", "output2")]
public void Method_WithVariousInputs_ReturnsExpectedOutputs(string input, string expected)
{
    // Test implementation
}
```

### Mocking
Dependencies are mocked using Moq:
```csharp
var mockService = new Mock<IService>();
mockService.Setup(x => x.Method(It.IsAny<string>())).Returns("mocked result");
```

### Test Data
Common test data is provided through the `TestHelper` class:
- Sample Caddyfile configurations
- Temporary file and directory creation
- Configuration builders

## Best Practices

1. **Test Naming**: Use descriptive names that indicate the method being tested, the condition, and the expected result
2. **Single Responsibility**: Each test should verify one specific behavior
3. **Independence**: Tests should not depend on each other and should be able to run in any order
4. **Cleanup**: Use `IDisposable` or cleanup methods to remove temporary resources
5. **Readable Assertions**: Use AwesomeAssertions for more readable test assertions
6. **Mock Verification**: Verify that mocked methods are called as expected when relevant

## Continuous Integration

These tests are designed to run in CI/CD environments and include:
- Fast execution times
- No external dependencies (except for Docker integration tests which are skipped)
- Comprehensive coverage of business logic
- Clear failure messages for debugging