【问题标题】:For a django unit test, why do some test runners take into account the production database, and others do not?对于 django 单元测试,为什么有些测试运行器会考虑生产数据库,而有些则不考虑?
【发布时间】:2013-10-13 15:29:16
【问题描述】:

作为 django 教程应用程序的一部分,我注意到某些测试运行器在运行单元测试时会转到生产数据库,而其他测试运行器似乎忽略了它。

我将 django 应用程序缩减为最基本的功能,进行了三个测试:

  • 模型实例化(控制测试)
  • 对空数据库的请求
  • 请求只有一个元素的数据库

我向生产数据库添加了一个元素,并通过 Eclipse PyDev 使用的测试运行器运行它们。

代码可在my GitHub site 获得。

django 测试运行器通过(声称正在创建测试数据库?):

(django)kenners@elendil:~/my_first_app$ python manage.py test demo
Creating test database for alias 'default'...
...
----------------------------------------------------------------------
Ran 3 tests in 0.135s

OK
Destroying test database for alias 'default'...

pytest 运行程序通过(没有任何此类声明,尽管它可能被隐藏):

(django)kenners@elendil:~/my_first_app$ python -m pytest demo/tests.py
=============================================================================== test session starts ================================================================================
platform linux2 -- Python 2.7.3 -- pytest-2.4.2
plugins: django
collected 3 items

demo/tests.py ...

============================================================================= 3 passed in 1.29 seconds =============================================================================

nose runner 失败(它正在将生产数据库与测试结合起来):

(django)kenners@elendil:~/my_first_app$ python -m nose demo/tests.py
FF.
======================================================================
FAIL: test_no_available_things (demo.tests.DemoDatabaseTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/kenners/my_first_app/demo/tests.py", line 23, in test_no_available_things
    self.assertEquals(0, pull_count_from_body(response))
AssertionError: 0 != 1

======================================================================
FAIL: test_one_available_things (demo.tests.DemoDatabaseTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/kenners/my_first_app/demo/tests.py", line 30, in test_one_available_things
    self.assertEquals(1, pull_count_from_body(response))
AssertionError: 1 != 2

----------------------------------------------------------------------
Ran 3 tests in 0.334s

FAILED (failures=2)

unittest2 运行器失败(原因相同):

(django)kenners@elendil:~/my_first_app$ python -m unittest2 demo.tests
FF.
======================================================================
FAIL: test_no_available_things (demo.tests.DemoDatabaseTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "demo/tests.py", line 23, in test_no_available_things
    self.assertEquals(0, pull_count_from_body(response))
AssertionError: 0 != 1

======================================================================
FAIL: test_one_available_things (demo.tests.DemoDatabaseTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "demo/tests.py", line 30, in test_one_available_things
    self.assertEquals(1, pull_count_from_body(response))
AssertionError: 1 != 2

----------------------------------------------------------------------
Ran 3 tests in 0.348s

FAILED (failures=2)

nose / unittest2 的哪一部分导致这些测试失败?为什么 pytest 有效?

【问题讨论】:

    标签: python django unit-testing nose pytest


    【解决方案1】:

    在运行单元测试时接触生产数据库是绝对不合适的。 单元测试通常应该在模拟数据库上工作。集成测试should work on a real,但测试数据库。 但是生产数据库呢?为什么要拿真实数据冒险?

    Django documentation 声称“测试运行器负责创建自己的测试数据库”。

    django-nose documentation 中可以清楚地看到它应该在测试数据库上运行测试。

    【讨论】:

    • 据我了解,django-nose 只是将nose testrunner 插入django 应用程序,这样python manage.py test 使用nose 而不是它使用的任何东西。这是不正确的吗?我可以尝试使用 django-nose,但我认为当我使用常规鼻子来测试 django 应用程序时,它是根本不同的......就像文档说的那样,python manage.py test 确实建立了一个测试数据库。我的问题是,这个数据库实例化实际发生在哪里?是在 django.test.TestCase 中,还是在运行测试套件之前有某种全局 testrunner 设置来 manage.py 调用?
    • @kenners,我认为我对 Django 的了解并不深,无法回答这个问题。 :(
    猜你喜欢
    • 2017-05-17
    • 2017-09-09
    • 2016-05-31
    • 2013-05-01
    • 2017-11-04
    • 2015-08-31
    • 2021-11-12
    • 2020-02-18
    • 2022-01-04
    相关资源
    最近更新 更多