Feature request: migration version aware test method.

[jvmlet]

Hi May I suggest a callback-like JUnit test method that should be invoked before/after migrating to specific version ? The intention is to be able to test DB at specific version/state. If this can be done with existing API, will be glad to get the guidlines. Thanks

[FlorianGWE]

Hi Alexander,

at the moment I do not understand really the reason what do you want do or test.

Flyway itself have a callback mechanismn where your callback will be invoked before or after each migration step. Flyway have not a feature to stop a complete migration on a specific point and I see also no reason why need this in update scenario.

Florian

[jvmlet]

Florian, I'm not suggesting to stop migration, I suggest to have a feature that allows me to define the unit test (class or method) to be invoked after migration to specific version is completed. This way I can have all the tests evolving together with schema without tweaking them for each and every schema change:

After V1:

main: V1. 0__init.sql test: V1.1__inserts.sql

@FlaywayVersionTest("V1.1")
class MyTest1{}// queries the DB to check the data consistently. 

After V2:

main: V1. 0__init.sql V2. 0__migrate.sql

test: V1.1__inserts.sql V2.1__inserts.sql

@FlaywayVersionTest("V1.1")
public class MyTest1{}

@FlaywayVersionTest("V2.1")
public class MyTest2{}

Does it make sense?

[FlorianGWE]

At the moment I miss your test point or project/database setup. For me it made no sense, but some hints I can give

1. Is your test MyTest1 no longer valid in your version 2.1. a) If it made no longer sense than delete your stuff. It is dead code. If it made sense so the test should also work after migrate your whole database to version 2.1. b) If you only want to reduce your test time you can specifiy some test suites with JUnit or select Test to execute with gradle or maven setup.
2. How big is your database migration script V2.0__migrate.sql . From a continue integration and dev ops point it should a small at possible and one time you added a migration script it should never be touched again. It is delivered. So database migration scripts do in my opinion only adding one fix or adding only one feature to your database. So you will get migration scripts V1.1.0a, V1.1.1b, V1.1.2__c and so on
3. Or will you test your migration script? Than in each software version you have a short time valid test and in the next version you do not need longer the test. So we are back at point 1.
4. What do you want to do with the migration when your Test MyTest1 will fail? If you rise a assert in a Flyway Callback the migration will be stopped with an error and you will have a corrupt database.
5. May be other test sql code setup can be. Each Test will do a complete clean, migrate step. But this is point 1 b).

   
   src/test/resource/test/sql/v11/V1.1__insert.sql
   src/test/resource/test/sql/v21/V2.1__insert.sql

// Code only insert 1.1 insert scripts @FlywayTest(locatsions="test/sql/v11") public class MyTest11

// Code only insert 2.1 insert scripts @FlywayTest(locatsions="test/sql/v11") public class MyTest11

[jvmlet]

Florian I fill that I need to provide more details about the proposed @FlaywayVersionTest annotation: the unit test method/class will be invoked when migration to the specified version is completed during migration cycle, this way you will never have dead code and will not have to delete/tweak ton of unit tests.

[jvmlet]

If you still think this is useless, you can close this issue