...

In this approach we would have a single test for single migration or small set of migrations that are close to each other. When a developer add a new migration(s), he/she will need to create a new test - and probably extends it by base version to not create a code duplication. Advantages of this approach is that each test represents a single migration, it is separate from other tests so we don't have to worry that one test will break something in another one. This approach respects single resposibility rule and creating custom tests should be easy - that does not match default pattern. Disadvantages contain things like a lot of test classes, more dificult to difficult to find a proper test class name - we can't name it ResourceMigrationTest because what if in the future there will be additional migrations for the given resource?

...

How create/get data for a test?

To verify that migrations are written correctly we need data on which those migrations will be executed. The data should be created in the way that they contain a typical and edge cases. For example if we copy values from one table to another by some field (where part of SQL statement) we should make sure that the field will contain different data. 

Additional data migrations

In this approach data are pushed to database by additional migrations defined for tests. Those migrations will not be present in the final JAR file. In this case it is easy to add a lot of data because we simple create a INSERT statements. Unfortunetly, those migrations will be threated in the same way as standard migrations so if in some place we put data, those data will be visible by all next migrations. Another issue can be with database contraint for example as a someone who create data/test I don't have to know that a resource with the given field already exist in the database and when I put exactly the same resource I could get an error message because of unique constraint. Tests will be harder to read because on the first look a developer will not know from where data are and why some verification checks are written in the given way.

Data generated by tests

In this approach data are generated in test before the test migration will be applied to database. Thanks this tests are easier to read because a developer will know what data are pushed to database and why some verification checks are written in the given way. Unfortunetly, in this case we will need to create additional classes/methods to put data into database. Also we can't use domain classes because they represent the final version of database and we need data in certain structure.