⭐ Testing Strategy

The Testing Strategy defines how the provisioning system is validated across all database engines. It ensures that StartActions, subsystems, and orchestration logic behave deterministically, securely, and consistently. Because each engine has unique requirements (SSL, keyfiles, config files, runtime flags, healthchecks), the testing strategy must cover both shared behavior and engine‑specific behavior.

This page explains the testing layers, the types of tests used, how engines are validated, and how the system ensures reliability across updates.

Purpose of the Testing Strategy The testing strategy ensures:

Deterministic provisioning

Correct environment variable generation

Correct volume creation

Correct SSL/TLS integration

Correct runtime flag injection

Correct Compose generation

Correct healthcheck behavior

Correct engine‑specific startup logic

It guarantees that the provisioning system behaves predictably across all supported engines.

Testing Layers The system uses four layers of tests:

1. Unit Tests Validate individual functions and subsystems.

Examples:

SSL certificate generation

Environment variable normalization

Volume path generation

Keyfile creation (MongoDB)

Compose fragment builders

2. Integration Tests Validate interactions between subsystems.

Examples:

StartAction + SSL subsystem

StartAction + Persistent Volumes

StartAction + Environment Variables

StartAction + Docker Orchestration

3. Engine‑Specific Tests Validate behavior unique to each database engine.

Examples:

MySQL authentication plugin flags

PostgreSQL TLS configuration

Redis/KeyDB/Dragonfly TLS flags

MongoDB keyfile authentication

4. Healthcheck Tests Validate that each engine reports readiness correctly.

Examples:

mysqladmin ping

pg_isready

redis-cli ping

keydb-cli ping

dragonfly ping

mongo --eval "db.adminCommand('ping')"

Test Coverage Goals The testing strategy aims for:

100% coverage of StartActions

100% coverage of SSL subsystem

100% coverage of volume generation

100% coverage of environment variable normalization

100% coverage of Compose generation

Full coverage of engine‑specific runtime flags

Full coverage of healthchecks

This ensures that provisioning logic is fully validated.

Engine‑Specific Testing Each engine has unique requirements that must be tested.

MySQL / MariaDB Root password required

Authentication plugin flag

SSL directory mount

Correct environment variables

Correct healthcheck

PostgreSQL Password required

TLS configuration in postgresql.conf

SSL directory mount

Correct environment variables

Correct healthcheck

Redis / KeyDB / Dragonfly Optional password

TLS flags

Multi‑threading flags (KeyDB/Dragonfly)

Correct environment variables

Correct healthcheck

MongoDB Keyfile authentication

Keyfile permissions

TLS flags

Correct environment variables

Correct healthcheck

Compose Generation Tests Compose generation is validated by checking:

Correct image

Correct ports

Correct volumes

Correct environment variables

Correct healthcheck

Correct runtime flags

Correct SSL mounts

Correct config mounts

Each engine has its own expected Compose structure.

Volume Tests Volume tests ensure:

Correct directory creation

Correct directory structure

Correct permissions

Correct mount paths

Correct engine‑specific directories

Examples:

/data/coolify/mysql//data /data/coolify/postgresql//data /data/coolify/mongodb//keyfile

SSL Tests SSL tests ensure:

CA certificate generated

Server certificate generated

Server key generated

Correct directory structure

Correct mount paths

Correct environment variables

Correct runtime flags

Environment Variable Tests Environment variable tests ensure:

Required variables exist

Optional variables are included when provided

SSL variables are included when SSL is enabled

No empty variables

Correct engine prefixes

Correct normalization

Healthcheck Tests Healthcheck tests ensure:

Correct command

Correct interval

Correct timeout

Correct retry count

Correct engine‑specific behavior