Scheduler Test Plan

Overview

This document describes the test strategy for the SchedulerDAO interface, its three persistence implementations (PostgreSQL, MySQL, SQLite), the SchedulerService layer, and the SchedulerResource REST API.

The goals are:

1. Ensure behavioral consistency across all three backends
2. Verify correctness at the DAO boundary, not just the happy path
3. Document non-obvious behavioral contracts (e.g. what happens when updateSchedule is called after setNextRunTimeInEpoch)
4. Verify Spring auto-configuration conditions wire the right beans for each backend
5. Provide a regression harness that automatically covers any future persistence implementations

Architecture: Shared Contract Tests

Problem

Before this plan was implemented, each persistence module had its own copy of the same ~339-line test class. Adding a test required updating three files. Missing one meant inconsistent coverage.

Solution: java-test-fixtures + Abstract Base Classes

conductor-scheduler uses Gradle's java-test-fixtures plugin to publish shared abstract test classes. Each persistence module's test class extends the relevant abstract class and provides only Spring wiring. There are three abstract bases:

conductor-scheduler/
  src/
    main/java/              <- SchedulerDAO interface + models + config
    test/java/              <- SchedulerResourceHttpTest (15 tests, MockMvc, no DB)
    testFixtures/java/
      .../dao/AbstractSchedulerDAOTest                       (34 tests)
      .../service/AbstractSchedulerServiceIntegrationTest    (8 tests)
      .../config/AbstractSchedulerAutoConfigurationSmokeTest (5 tests)

conductor-scheduler-postgres-persistence/
  src/test/java/
    .../dao/PostgresSchedulerDAOTest
    .../service/PostgresSchedulerServiceIntegrationTest
    .../config/PostgresSchedulerAutoConfigurationSmokeTest

conductor-scheduler-mysql-persistence/
  src/test/java/
    .../dao/MySQLSchedulerDAOTest
    .../service/MySQLSchedulerServiceIntegrationTest
    .../config/MySQLSchedulerAutoConfigurationSmokeTest

conductor-scheduler-sqlite-persistence/
  src/test/java/
    .../dao/SqliteSchedulerDAOTest
    .../service/SqliteSchedulerServiceIntegrationTest
    .../config/SqliteSchedulerAutoConfigurationSmokeTest

Each persistence module declares:

testImplementation testFixtures(project(':conductor-scheduler'))

Adding a test: write it once in the relevant abstract class — all three backends run it automatically on the next build.

Test Environments

SQLite uses hikari.maximum-pool-size=1 because in-memory databases are connection-scoped in SQLite. A single HikariCP connection is kept alive for the duration of the test suite.

All modules run Flyway migrations in @TestConfiguration with a dedicated history table (flyway_schema_history_scheduler) to avoid conflicting with any main Conductor migration history present in the same schema.

Test Categories and Rationale

1. Schedule CRUD (11 tests) — AbstractSchedulerDAOTest

Basic create/read/update/delete coverage plus edge cases:

2. JSON Round-trip Fidelity (3 tests) — AbstractSchedulerDAOTest

Each DAO stores models as JSON blobs. This category verifies no field silently drops during serialization/deserialization. The original tests checked only 4 fields; these cover the rest.

3. Execution Tracking (10 tests) — AbstractSchedulerDAOTest

The POLLED -> EXECUTED/FAILED lifecycle plus state-dependent queries:

4. Next-run Time Management (3 tests) — AbstractSchedulerDAOTest

The next_run_time column is written by two separate operations; their interaction needs explicit documentation:

5. Volume (1 test) — AbstractSchedulerDAOTest

6. Concurrency (1 test) — AbstractSchedulerDAOTest

7. Case Sensitivity + Error Conditions (5 tests) — AbstractSchedulerDAOTest

8. Service Layer Integration (8 tests) — AbstractSchedulerServiceIntegrationTest

Wires a real SchedulerDAO (from the concrete subclass) with a real SchedulerService and a mocked WorkflowService. No background scheduler thread starts. Tests service logic against actual SQL:

9. HTTP Layer (15 tests) — SchedulerResourceHttpTest

Uses MockMvcBuilders.standaloneSetup with a local exception handler. No database needed — all SchedulerService calls are mocked. Lives in conductor-scheduler/src/test (runs once, not per-backend):

10. Auto-configuration Smoke Tests (5 tests) — AbstractSchedulerAutoConfigurationSmokeTest

Uses Spring Boot's ApplicationContextRunner to verify that @ConditionalOnExpression guards on each persistence module's @AutoConfiguration class work correctly. These tests catch bugs the DAO and service integration tests cannot, because those tests bypass auto-configuration and wire beans manually:

Bugs caught exclusively by these tests:

• Typo in the condition string (e.g. 'postgresql' instead of 'postgres')
• Missing or wrong classname in META-INF/spring/...AutoConfiguration.imports

Running the Tests

# All three backends (DAO + service integration + smoke):
DOCKER_API_VERSION=1.44 ./gradlew \
    :conductor-scheduler-postgres-persistence:test \
    :conductor-scheduler-mysql-persistence:test \
    :conductor-scheduler-sqlite-persistence:test

# HTTP layer tests (no Docker):
./gradlew :conductor-scheduler:test

# SQLite only — fastest full run, no Docker needed:
./gradlew :conductor-scheduler:test :conductor-scheduler-sqlite-persistence:test

macOS note: Testcontainers (used for Postgres and MySQL) requires Docker Desktop to be running. The test builds set environment 'DOCKER_API_VERSION', '1.44' in their test blocks to avoid a Testcontainers/docker-java version mismatch on Docker Desktop.

Results

Adding New Tests

DAO contract test (runs on all three backends automatically)

1. Open scheduler/src/testFixtures/java/.../dao/AbstractSchedulerDAOTest.java
2. Add a @Test method
3. Run any one of the three persistence modules to verify

Service integration test (runs on all three backends automatically)

1. Open scheduler/src/testFixtures/java/.../service/AbstractSchedulerServiceIntegrationTest.java
2. Add a @Test method

HTTP layer test (runs once, no database)

1. Open scheduler/src/test/java/.../rest/SchedulerResourceHttpTest.java
2. Add a @Test method using the existing mockMvc and mockService fields

Auto-configuration smoke test (runs on all three backends automatically)

1. Open scheduler/src/testFixtures/java/.../config/AbstractSchedulerAutoConfigurationSmokeTest.java
2. Add a @Test method using baseRunner() and withPropertyValues(...)

If a test needs to be skipped for a specific backend (e.g. a SQL feature not available in SQLite), the concrete test class can override and annotate with @Ignore or use assumeTrue.

Relationship Between Test Layers

Layer                      | Scope                              | DB needed
---------------------------|------------------------------------|----------
DAO contract tests         | SQL correctness, data fidelity     | Yes (real DB)
Service integration tests  | Service logic against real storage | Yes (real DB)
HTTP tests                 | REST status codes, request mapping | No (MockMvc)
Auto-config smoke tests    | Spring wiring conditions           | Only for positive path

Each layer has blind spots the others fill:

• DAO tests bypass auto-config (can't catch condition string typos)
• Service tests bypass HTTP (can't catch routing or marshalling bugs)
• HTTP tests use mocked service (can't catch SQL bugs)
• Smoke tests use a fresh context (can't catch SQL bugs, but verify the wiring happens at all)