Handling of / keeping data from migrations?

[blueyed]

Sorry for my ignorance, but does this handle / keep / restore data being created during migrations?

The typical problem is that Django's flush (called with TransactionTestcase) will empty the tables, but keeps their structure migrated (see pytest-dev/pytest-django#220 (comment) for more information / discussion in this regard), and migrations won't be run again (the migrations table/info is kept).

[plumdog]

If we have a test case that has before = '0001' and after = '0002', then when we call self.run_migration, we run the 0002 migration. Any data added by the 0001 migration will not appear from the setUp. The idea being that your tests should only test the migrations they are intended to test (in this case, 0002), not all the migrations before it. If there's data that you need to load before you run 0002, then you should load it in the setUp of your TestCase. If you want to test your "full run" then you can set before = 'zero' and after = [[your-latest-migration]]. (I'm not actually 100% certain if this behaviour is the same depending on whether you're using south or django migrations.)

Let me know if this fits your use case. I'd be interested to know if there would be a useful alteration/option to add.

[blueyed]

What I've meant is related to data migrations in general: e.g. you are creating a user in some early migration, and then test some migrations: because of using TransactionTestCase the DB tables will be flushed, and your user is not available anymore for other tests.

That appears to be a general problem with data migrations in tests, where you also use TransactionTestCase, but maybe this app helps or could help with that.

See also my comment at pytest-dev/pytest-django#258 (comment), which plays with the idea of using snapshots of the database via https://github.com/fastmonkeys/stellar.

[plumdog]

I think - by default, at least - that it shouldn't. I'd rather that the test cases don't depend on data from earlier migrations. If there's an alteration to the setUp that would make it easier to extend the class and snapshot the state of the database, then I'd be happy to do that, but I'd rather not explicitly integrate it with snapshot tool.