Почему для модульного теста django некоторые участники тестирования принимают во внимание производственную базу данных, а другие - нет?

В рамках создания учебного приложения по django я заметил, что некоторые участники тестирования обращались к производственной базе данных при запуске модульных тестов, в то время как другие участники тестирования игнорировали это.

Я сократил приложение django до самых основных функций с помощью трех тестов:

  • Создание экземпляра модели (контрольный тест)
  • Запрос на пустую базу данных
  • Запрос к базе данных с ровно одним элементом

Я добавил один элемент в производственную базу данных и прогнал их через тестовые программы, которые использует Eclipse PyDev.

Код доступен на моем сайте GitHub.

Программа запуска тестов 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 =============================================================================

Носовой бегун терпит неудачу (объединяет производственную базу данных с тестами):

(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)

Какая часть носа / unittest2 приводит к сбою этих тестов? Почему работает pytest?


person kenners    schedule 07.10.2013    source источник


Ответы (1)


Прикасаться к производственной базе данных при запуске юнит-тестов совершенно неуместно. Модульные тесты обычно должны работать с имитацией базы данных. Интеграционные тесты должны работать на реальной, но тестовой базе данных. Но производственная база данных? Зачем вам рисковать своими настоящими данными?

Документация Django утверждает, что "средство выполнения тестов заботится о создании собственной тестовой базы данных. ".

В документации django-носа ясно видно, что это предполагается для запуска тестов в тестовой базе данных.

person Denis    schedule 07.10.2013
comment
Насколько я понимаю, django-нос просто вставляет средство проверки носа в приложение django, так что python manage.py test использует нос вместо того, что он использует. Это неправильно? Я могу попробовать использовать django-нос, но я думаю, что это принципиально другое, когда я использую обычный нос для тестирования приложения django ... Как говорят документы, python manage.py test действительно поддерживает тестовую базу данных. У меня вопрос: где на самом деле происходит создание экземпляра БД? Находится ли он внутри django.test.TestCase, или есть какая-то глобальная установка testrunner, которая вызывает manage.py перед запуском набора тестов? - person kenners; 08.10.2013
comment
@kenners, я не думаю, что знаю Django настолько глубоко, чтобы ответить на этот вопрос. :( - person Denis; 08.10.2013