我们已经使用django迁移（django v1.7 +）更改了数据库。数据库中存在的数据不再有效。
基本上，我想通过在单元测试中构建迁移前的数据库，添加一些数据，应用迁移，然后确认一切顺利进行来测试迁移。
如何：
加载单元测试时阻止新的迁移
我发现了一些有关覆盖的内容，settings.MIGRATION_MODULES但无法弄清楚如何使用它。当我检查时，executor.loader.applied_migrations它仍然列出了所有内容。我阻止新迁移的唯一方法是实际删除文件。不是我可以使用的解决方案。
在unittest数据库中创建一条记录（使用旧模型）
如果我们可以防止迁移，那么这应该很简单。 myModel.object.create(...)
应用迁移
我想我已经找到了test_executor，现在可以解决这个问题：设置一个指向迁移文件的计划并执行它？嗯对不对 得到了任何代码：-D
确认数据库中的旧数据现在与新模型匹配
再次，我希望这应该很容易：只需获取在迁移之前创建的实例，并确认它已经以所有正确的方式进行了更改。
因此，挑战实际上只是弄清楚如何防止单元测试应用最新的迁移脚本，然后在准备就绪后再应用它？
也许我有错误的做法？我应该创建固定装置，然后确认它们在最后都很好吗？在应用迁移之前或完成迁移之后，是否加载了夹具？
通过使用MigrationExecutor和选择特定的迁移，.migrate我能够（也许？）将其回滚到特定状态，然后一个接一个地向前滚动。但这引起了人们的怀疑。由于缺少实际的ALTER TABLE指令，目前正在跟踪sqlite混乱。陪审团还在。
我无法阻止单元测试的开始与当前数据库架构，但我没有找到它是很容易恢复到在迁移历史较早点：
其中“ 0014_nulls_permitted”是迁移目录中的文件...
from django.db.migrations.executor import MigrationExecutor
executor.migrate([("workflow_engine", "0014_nulls_permitted")])
executor.loader.build_graph()
注意： 在两次调用之间运行似乎是完成迁移并使事情按预期运行的非常重要的一部分executor.loader.build_graphexecutor.migrate
当前适用于数据库的迁移可以通过以下方式进行检查：
print [x[1] for x in sorted(executor.loader.applied_migrations)]
[u'0001_initial', u'0002_fix_foreignkeys', ... u'0014_nulls_permitted']
我通过ORM创建了一个模型实例，然后通过直接运行一些SQL来确保数据库处于旧状态：
job = Job.objects.create(....)
from django.db import connection
cursor = connection.cursor()
cursor.execute('UPDATE workflow_engine_job SET next_job_state=NULL')
伟大的。现在，我知道我的数据库处于旧状态，并且可以测试正向迁移。因此，0016_nulls_banished是迁移文件：
executor.migrate([("workflow_engine", "0016_nulls_banished")])
executor.loader.build_graph()
迁移0015通过数据库将所有NULL字段转换为默认值。迁移0016会更改架构。您可以散布一些打印语句，以确认事情如预期的那样发生。
现在，该测试可以确认迁移已成功进行。在这种情况下，请确保数据库中没有空值。
jobs = Job.objects.all()
self.assertTrue(all([j.next_job_state is not None for j in jobs]))
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句