Flamingock: Testing

This section documents schema/database evolution using version-controlled migration tools — Liquibase (relational/SQL), Mongock (MongoDB, Java-native) and Flamingock (Mongock’s successor, generalized to any external system) — as described by each tool’s own official documentation: liquibase.org and docs.liquibase.com for Liquibase, docs.mongock.io for Mongock, and docs.flamingock.io for Flamingock — which are the references these pages are written and verified against.

This content was generated with the assistance of AI and should be verified against those official docs before being relied on in production.

Mongock is now maintained under the Flamingock GitHub organization (github.com/flamingock/mongock), and Flamingock is positioned as its successor — see Coming from Mongock. Readers starting a new project should default to Flamingock unless they have a specific reason to stay on Mongock.

This section’s bibliography lists the reference material consulted while preparing these pages.

The Change Validator

Flamingock’s audit store (Flamingock: Changes & Target Systems) records intermediate execution states as a Change runs — STARTED, APPLIED, ROLLED_BACK, and so on — not just a final outcome. The change validator filters that raw audit log down to final outcomes, so a test can assert "this Change ended up applied" without having to know or filter out every transient state the audit log recorded along the way.

Unit Testing a Single Change

Because a @Change class is plain Java with @Apply/@Rollback methods (Flamingock: Changes & Target Systems), it can be unit tested like any other class — instantiate it, call apply(…) with a mocked or in-memory target-system client, and assert on the result, independent of Flamingock’s own execution machinery. This is the fastest layer of testing and the right place to verify a Change’s logic in isolation, before involving Flamingock’s runner at all.

The BDD-Style Given-When-Then API

Flamingock also provides a BDD-style testing API, shared between standalone and Spring Boot tests, built around three steps — given, when, verify — where nothing executes until verify() is called:

FlamingockTest
    .given(state -> state.collection("person").insertOne(new Document("_id", 1).append("email", null)))
    .when(runner -> runner.execute("create-person-index"))
    .verify(result -> {
        assertThat(result.wasApplied("create-person-index")).isTrue();
        assertThat(indexExists("person", "email")).isTrue();
    });

The given step seeds preconditions (existing data, an existing index), when names which Change(s) to execute, and verify runs the assertions — deferring execution to verify() keeps the three steps declarative and readable as a single fluent chain, rather than needing explicit setup/teardown around an imperative test body.

Spring Boot Integration Testing

For a Spring Boot application, the same BDD-style API integrates with Spring’s test context, so a test can boot the application context (or a slice of it), let Flamingock run its normal startup migration flow, and then use the change validator or the BDD API to assert against the real, fully-wired target-system beans instead of mocks — the appropriate level for confirming a Change behaves correctly against the actual Spring Data MongoTemplate/JdbcTemplate configuration the application uses in production, rather than a hand-constructed client in a plain unit test.

See Flamingock BDD API for the full API reference and Spring Boot test-slice configuration.