Testing

This section documents Authelia's testing processes and procedures to ensure code quality and reliability.

Types of Testing

Authelia performs multiple types of testing:

• Linting to enforce code quality and uniform style.
• Unit testing to test code in isolation from other code to protect against regressions and unintended behavior.
• Integration testing to test the application in combination with various external dependencies including:
  • Databases
  • Reverse Proxies
  • Memory Caching
  • Identity Backends (LDAP, AD, File)
• End-to-End testing to test application features work properly under all supported conditions.
• Automated Secrets Scanning using GitGuardian.
• GitHub Runner Monitoring using StepSecurity Harden-Runner.

Automated Testing

Continuous Integration

Testing is automatically executed on:

• Every push to a branch.
• Every pull request submission and revision, subject to approval for 3rd party pull requests.
• Merges to the main branch.
• Documentation-only changes do not trigger the full test suite.

Test Execution Pipeline

We make use of Buildkite as our CI/CD platform. All automated testing for public code is visible from the Authelia Buildkite Dashboard. A complete testing suite run averages ~9 minutes, subject to fluctuation. Testing agents are run on our hosted infrastructure using our custom runner image.

Test Coverage

Authelia maintains comprehensive code coverage metrics to ensure thorough testing of the codebase:

• Coverage reports are automatically generated for every test run.
• Current coverage statistics and trends are available on our Codecov dashboard.
• Coverage is tracked separately for:
  • Backend: Go code in cmd/authelia/ and internal/ directories
  • Frontend: JS/TS code in web/ directory
• Coverage targets: 70-100% with precision to 2 decimals.
• Pull requests must not decrease coverage by more than 0.15% for either component.
• Coverage is tracked for unit and integration testing.
• Coverage excludes test mocks, test suites, and generated files.
• Pull requests display coverage changes to maintain visibility during development.

Merge and Release Requirements

Pull Request Testing

• All testing suites must pass before merge approval.
• Tests run automatically via Buildkite.

Release Testing

• Full test suite execution before any release.
• For additional security measures related to releases see our security measures.

Test Validation

• Test results are automatically reported in pull requests.
• Release candidates require 100% pass rate.