blocks|key|1204694|text|首先，如果您在生产数据库上运行它，那么它并不是一个“单元”测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1204695|它是一流的批处理作业，需要像对待一流的生产批处理作业一样对待。|1204696|您不能使用Django+test命令来查看生产数据。它总是创建一个空数据库，该数据库由TestCase中的fixture填充。|offset|length|style|CODE|1204697|您可以使您的生产数据库处理一个适当的management+command。这已经正确配置了环境，这样您的命令就可以简单地使用Django+ORM来处理数据。|1204698|另一种方法是确保您配置了settings。使用DJANGO_SETTINGS_MODULE环境变量或使用settings.configure()函数创建环境。|1204699|然后，您可以导入模型并对生产数据库执行您想要执行的处理。|1204700|如果您愿意，您可以将其称为"test“，但是您正在查看生产数据，因此在获取设置文件和使用正确的ORM配置方面，必须将其视为生产应用程序。|1204701|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.djangoproject.com/en/dev/howto/custom-management-commands/#writing-custom-django-admin-commands|1|http://docs.djangoproject.com/en/dev/topics/settings/#topics-settings^0|0|0|C|4|0|I|I|0|0|N|M|1G|K|C|8|1|0|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|12|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|13|8|@$F|14|G|15|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|16|8|@]|9|@$F|17|G|18|1|19]]|A|$]]|$1|L|3|M|5|6|7|1A|8|@$F|1B|G|1C|H|I]|$F|1D|G|1E|H|I]]|9|@$F|1F|G|1G|1|1H]]|A|$]]|$1|N|3|O|5|6|7|1I|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1J|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|S|$T|$5|U|V|W|A|$X|Y]]|Z|$5|U|V|W|A|$X|10]]]]

First, if you're running it on the production database, it isn't much of a "unit" test.

It's a first-class batch job and needs to be treated like a first-class production batch job.

You cam't to use the Django <code>test</code> command for looking at production data. It always creates an empty database which is populated from fixtures in the TestCase.

You could make your production database processing a proper <a href="http://docs.djangoproject.com/en/dev/howto/custom-management-commands/#writing-custom-django-admin-commands" rel="noreferrer">management command</a>. This has the environment all properly configured so that your command can simply use the Django ORM to process your data.

The alternative is to be sure that you configure your <a href="http://docs.djangoproject.com/en/dev/topics/settings/#topics-settings" rel="noreferrer">settings</a>. Either
use the <code>DJANGO_SETTINGS_MODULE</code> environment variable or use the <code>settings.configure()</code> function to create an environment.

You can then import the models and do the processing you want to do against the production database.

You can call it "test" if you want to, but you're looking at production data, so it's got to be treated like production application with respect to getting the settings file and using the proper ORM configuration.

blocks|key|1419833|text|单元测试的目的是测试没有任何副作用。尽管你的测试并不是单元测试。如果您仍然想这样做，您可以使用正在设置数据库的自定义测试运行器(或者在您的情况下使用现有的db)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1419834|您可以在settings.py文件中设置TEST_RUNNER设置。默认值为locate+in+django.test.simple.run_tests。您可以在此处查看源代码：http://code.djangoproject.com/browser/django/trunk/django/test/simple.py|offset|length|style|CODE|1419835|将代码复制并粘贴到新文件中，然后从代码中删除以下行：|1419836|connection.creation.create_test_db(verbosity,+autoclobber=not+interactive)|1419837|..。|1419838|connection.creation.destroy_test_db(old_name,+verbosity)|1419839|这将阻止django创建测试数据库并重置设置文件的数据库配置。|1419840|entityMap|0|LINK|mutability|MUTABLE|url|http://code.djangoproject.com/browser/django/trunk/django/test/simple.py^0|0|1C|S|2H|20|0|0|0|0|22|0|0|0|1K|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@$D|11|E|12|F|G]]|9|@$D|13|E|14|1|15]]|A|$]]|$1|H|3|I|5|6|7|16|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|17|8|@$D|18|E|19|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1A|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1B|8|@$D|1C|E|1D|F|G]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1E|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]]|S|$T|$5|U|V|W|A|$X|Y]]]]

A unittest is meant to test without any sideeffects. Though your test would be nothing that is known as unittest. If you want to do it anyway, you can use a custom test runner that is setting up the database (or in your case using the existing db).

You can set the TEST_RUNNER setting in your settings.py file. The default is locate in <code>django.test.simple.run_tests</code>. You can look at the source here:
<a href="http://code.djangoproject.com/browser/django/trunk/django/test/simple.py" rel="nofollow noreferrer">http://code.djangoproject.com/browser/django/trunk/django/test/simple.py</a>

Copy and paste the code in a new file and remove the following lines from the code:

<code>connection.creation.create_test_db(verbosity, autoclobber=not interactive)</code> 
... 
<code>connection.creation.destroy_test_db(old_name, verbosity)</code>

This will prevent django from creating a test database and reseting the database configuration of your settings file.

blocks|key|1204761|text|这个TEST_RUNNER可以在Django1.3上运行|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1204762|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|code-block|syntax|javascript|1204763|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

This TEST_RUNNER works on Django 1.3

<pre><code>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
</code></pre>

blocks|key|1204782|text|这不是一个好主意，但是如果你知道你在做什么(基本上破坏了你的生产)，你可以检查这个设置：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1204783|https://docs.djangoproject.com/en/2.2/ref/settings/#test|offset|length|1204784|DATABASES+=+{
++'default':+{
+++++...
+++++'TEST':+{
++++++++'NAME':+'your+prod+db'
+++++}
}|code-block|syntax|javascript|1204785|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1K|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|H|7|W|8|@]|9|@]|A|$I|J]]|$1|K|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|L|$M|$5|N|O|P|A|$Q|C]]]]

Not a good idea, but if you know what you are doing (basically breaking your production) you can check this setting: 

<a href="https://docs.djangoproject.com/en/2.2/ref/settings/#test" rel="nofollow noreferrer">https://docs.djangoproject.com/en/2.2/ref/settings/#test</a>

<pre><code>DATABASES = {
 'default': {
 ...
 'TEST': {
 'NAME': 'your prod db'
 }
}
</code></pre>

i'm starting the TDD development attitude and am writting unit-tests for my django application. I'm aware of fixtures and know that's the way tests should be executed, but for a given test i do need to execute it on the whole database, and json fixture for 10+ million row database is not something i'd like to handle, moreover, this test is "read-only".

So the question is how are you setting up your test suites to run on the production database? I imagine it could be as easy as adding the DATABASE_NAME setting in the setUp method of certain test. But the settings.DATABASE_NAME="prod_db" results in "NameError: global name 'settings' is not defined" while running the test. Moreover, there is a risk described in <a href="http://code.djangoproject.com/ticket/11987" rel="noreferrer">http://code.djangoproject.com/ticket/11987</a>, that you can accidentally delete a production database. 

So, how is it possible, or, even better, what is best practice, to run a single test of a test suite on a production database instead of temporary one?

Cheers in advance for any opinions!

How to run django unit-tests on production database?

单元测试

数据库

Django

我开始了TDD开发态度，并且正在为我的django应用程序编写单元测试。我知道fixture是应该执行测试的方式，但是对于一个给定的测试，我确实需要在整个数据库上执行它，而10+百万行数据库的json fixture不是我想要处理的东西，而且，这个测试是“只读的”。因此，问题是如何设置测试套件以在生产数据库上运行？我想...

问如何在生产数据库上运行django单元测试？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何在生产数据库上运行django单元测试？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何在生产数据库上运行django单元测试？
EN