Django 测试使用现有数据库

发布于 2024-11-13 23:25:04 字数 207 浏览 10 评论 0原文

我很难自定义测试数据库设置行为。我想实现以下目标:

  • 测试套件需要使用现有数据库
  • 测试套件不应删除或重​​新创建数据库,而是从 mysql 转储加载数据
  • 由于数据库是从转储填充的,因此不应加载任何固定装置
  • 完成测试后,数据库不应被破坏

,我很难让 testsuiterunner 绕过创建。

I'm having a hard time customizing the test database setup behavior. I would like to achieve the following:

  • The test suites need to use an existing database
  • The test suite shouldn't erase or recreate the database instead load the data from a mysql dump
  • Since the db is populated from a dump, no fixtures should be loaded
  • Upon finishing tests the database shouldn't be destroyed

I'm having a hard time getting the testsuiterunner to bypass creation.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

甜警司 2024-11-20 23:25:04

快进到 2016 年,django 中内置了在测试之间保留数据库的功能。它以 --keep 标志的形式提供 管理.py

Django 1.8 中的新增功能。在测试运行之间保留测试数据库。这
具有跳过创建和销毁操作的优点
这可以大大减少运行测试的时间,尤其是那些
一个大型测试套件。如果测试数据库不存在,则会
在第一次运行时创建,然后为后续每次运行保留。
任何未应用的迁移也将应用于测试数据库
在运行测试套件之前。

这几乎满足了您在问题中提到的所有标准。事实上,它甚至更进一步。无需在每次运行之前导入转储。

Fast forward to 2016 and the ability to retain the database between tests has been built into django. It's available in the form of the --keep flag to manage.py

New in Django 1.8. Preserves the test database between test runs. This
has the advantage of skipping both the create and destroy actions
which can greatly decrease the time to run tests, especially those in
a large test suite. If the test database does not exist, it will be
created on the first run and then preserved for each subsequent run.
Any unapplied migrations will also be applied to the test database
before running the test suite.

This pretty much fullfills all the criteria you have mentioned in your questions. In fact it even goes one step further. There is no need to import the dump before each and every run.

薆情海 2024-11-20 23:25:04

此 TEST_RUNNER 适用于 Django 1.3

from django.test.simple import DjangoTestSuiteRunner as TestRunner

class DjangoTestSuiteRunner(TestRunner):
    def setup_databases(self, **kwargs):
        pass

    def teardown_databases(self, old_config, **kwargs):
        pass

This TEST_RUNNER works in Django 1.3

from django.test.simple import DjangoTestSuiteRunner as TestRunner

class DjangoTestSuiteRunner(TestRunner):
    def setup_databases(self, **kwargs):
        pass

    def teardown_databases(self, old_config, **kwargs):
        pass
水中月 2024-11-20 23:25:04

您需要提供自定义测试运行程序。

您有兴趣使用默认 django 覆盖的位。 test.runner.DiscoverRunnerDiscoverRunner.setup_databasesDiscoverRunner.teardown_databases 方法。这两个方法涉及创建和销毁测试数据库,并且仅执行一次。您需要提供特定于测试的项目设置,默认情况下使用现有的测试数据库并覆盖这些设置,以便加载转储数据并且不会破坏测试数据库。

根据转储的大小和内容,安全的选择可能是只创建一个子进程,将转储通过管道传输到数据库的 SQL 命令行界面,否则您可能会获得游标和 直接执行查询

如果您希望完全摆脱固定装置加载,您可以提供一个自定义基本测试用例来扩展 Django 的默认 django.test.testcases.TestCaseTestCase._fixutre_setupTestCase._fixutre_teardown 方法被重写为 noop。

买者自负:此运行程序将无法促进除应用程序源之外的任何内容的测试。可以自定义运行程序以创建特定别名以连接到现有数据库并加载转储,然后提供覆盖 TestCase._database_names 指向它的别名。

You'll need to provide a custom test runner.

The bits your interested in overriding with the default django.test.runner.DiscoverRunner are the DiscoverRunner.setup_databases and DiscoverRunner.teardown_databases methods. These two methods are involved with creating and destroying test databases and are executed only once. You'll want to provide test-specific project settings that use your existing test database by default and override these so that the dump data is loaded and the test database isn't destroyed.

Depending on the size and contents of the dump, a safe bet might be to just create a subprocess that will pipe the dump to your database's SQL command-line interface, otherwise you might be able to obtain a cursor and execute queries directly.

If your looking to get rid of fixture loading completely, you can provide a custom base test case that extends Django's default django.test.testcases.TestCase with the TestCase._fixutre_setup and TestCase._fixutre_teardown methods overriden to be noop.

Caveat emptor: this runner will make it impossible to facilitate tests for anything but your application's sources. It's possible to customize the runner to create a specific alias for a connection to your existing database and load the dump, then provide a custom test case that overrides TestCase._database_names to point to it's alias.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文