Open
Description
At this moment test-data
context follow the same rules as others. Let's extract it and put it aside as it's different than others because it's applied to an in-memory database that is always created from scratch.
Advantages of the current approach:
test-data
is treated similarly toprod-data
: the migrations that modify data also applied to test data. This might help to catch mistakes in such migrations on early stages. But it can't catch them all and that's what Build scripts: check database upgrade before deploy #383 should cover.
Disadvantages of the current approach:
- Adding a new test record in a table becomes difficult over time because a table structure is scattered between many migrations. This means that in order to identify what columns a table have, we need to look on all migrations that touched this table or we need to run a server and inspect a table in H2 console.
- The similar applies to test data -- it's hard to predict what ID a new record would have because it requires to inspect all migrations.
- copying&pasting isn't reliable as a table structure might have changed between migrations
- when we add another one test record to a table, we can append it into an existing migration but after that a migration filename might get outdated. In this case, we can rename a file but it might be unsafe (as Liquibase remembers filenames).
- because there is no way to distinguish changes of test-data from other types of change, we can't configure Danger to complain when migrations that touche non-test data have been modified.