5

Usually migration script is simple like adding new column or so and if applications if deployed then everything is ok. but sometimes there is some complex logic involved that should be tested. what is the recommended approach?

piotrek
  • 13,982
  • 13
  • 79
  • 165

1 Answers1

10

Have a separate DB for testing. Migrate it as part of every build and run tests against it. You can also populate it with extra test data as you desire by including a second location for test data migrations.

Main Location:

  • V1__Initial.sql
  • V2__More_changes.sql
  • V3__Complex_logic.sql

Test data location:

  • V2.1__Test_data.sql

You can then call flyway.clean() and flyway.migrate() in a test before asserting whether the test data got transformed correctly.

Axel Fontaine
  • 34,542
  • 16
  • 106
  • 137
  • i see two problems with this approach: 1) we have 'global' data for all tests instead of preparing independent data for a specific test 2) soon there will be V4__whatever.sql so my tests won't be valid any more. is there any way to run tests before the migration proceeds? feature request? :) – piotrek Apr 28 '14 at 09:13
  • 1
    You can set flyway.target to 3, so it'll only migrate that far. – Axel Fontaine Apr 28 '14 at 11:00
  • yes, i can do it manually but it doesn't scale. tests should be automatic. almost all the tests require the latests db version. only migration requires earlier version. how can i run some tests on V1 some on V2 etc and rest on most recent version? i'm not sure how to correctly set up the whole production-ready process – piotrek Apr 29 '14 at 19:07
  • 1
    Who said you should do it manually? Use multiple databases or multiple schemas. Flyway can easily create additional schemas automatically for you. – Axel Fontaine May 01 '14 at 11:53