Question about database migration tests

[wenley3805-star]

Hi,
I’m a student currently taking a Software Testing course, and I'm using your software as part of my assignment content. Can anyone give me some advice on a testing issue:

I’m running the database migration tests and noticed that migrations fail for versions 52–67, while version 68 succeeds.

After tracing the code, the failure happens during the initialization of MigrationBase, not during the actual migration steps. In MigrationBase.init, there is a strict validation that requires every table in migration_mapping to have a migration history length exactly equal to:

DATABASE_VERSION + 1 - FIRST_DATABASE_VERSION_SUPPORTED

When testing migrations starting from versions 52–67, this validation is triggered and fails, causing a TypeError that is caught by update_db() and returned as -1. Since the exception is swallowed, the test only reports a generic failure.

For version 68, the migration path is skipped (perform_data_update is called instead of perform_migration), so the validation logic is never executed, which explains why that test passes.

From a testing perspective, this looks like the migration framework enforces a full, end-to-end migration history for all tables, even when running partial or legacy migration tests. Could anyone clarify whether versions 52–67 are still intended to be supported as valid upgrade paths, or if the test range (or FIRST_DATABASE_VERSION_SUPPORTED) should be adjusted accordingly?

Thanks!

[evilaliv3]

Hi @wenley3805-star,

thank you very much for reaching out! We’re really glad to see you engaging with our software and sharing your questions. It’s great to know it’s being used for your assignment.

You are correct in noticing that the migration framework enforces a full migration history for all tables, and that this can affect tests starting from older versions. Your explanation of why versions 52–67 fail while version 68 passes is accurate: the validation in MigrationBase.init is strict, and partial or legacy migration tests may trigger it if the history does not match the expected length.

As for whether versions 52–67 are intended to be supported, that depends on the current FIRST_DATABASE_VERSION_SUPPORTED setting and the migration policy. If you are focusing on testing more recent upgrade paths, it may make sense to adjust your test range or the FIRST_DATABASE_VERSION_SUPPORTED constant. Otherwise, running migrations from older versions requires creating or simulating a complete migration history in the test database to pass validation.

We include old migrations because users that might have installed the software yeards ago (e.g. in 2020) might still require to update and we want to offer them this possibility.

Regarding your observations, I have a few questions to start with:

1. Which branch are you using for your tests?
   We recommend using the stable branch, where all tests are expected to pass successfully.

2. What are you trying to achieve exactly?
   If you could provide a bit more context and, if possible, share your patch, we could better guide you.

Writing a migration script in GlobaLeaks is not trivial, as migrations are quite custom. That said, here is the general process you should follow:

First, edit the database to apply your changes.

1. Instantiate a new database version in backend/globaleaks/init.py by increasing the database version number (e.g. DATABASE_VERSION = 69).

2. Launch the app to generate a database with your changes. The database will be created in backend/workingdir/globaleaks.db.

3. Copy the database into backend/globaleaks/tests/db/empty and backend/globaleaks/tests/db/populated
   (The populated directory contains databases initialized via end-to-end tests. We archive both empty and populated databases specifically to retest the software and its migrations over time.)

Extend the migration table in backend/globaleaks/db/migration.py and write the migration script in
backend/globaleaks/db/migrations/update_69/init.py.
You can look at the existing migration files to better understand how they work.

[wenley3805-star]

Thank you so much! This really helped a lot! I'm just exploring this project to better understand how testing works in a large codebase and documenting it as a report. From a long-term maintenance perspective, this design totally makes sense.