Как запустить модульный тест для производственной базы данных? - PullRequest
5 голосов
/ 07 апреля 2010

Как запустить модульный тест для рабочей базы данных вместо тестовой базы данных?

У меня есть ошибка, которая возникает на моем рабочем сервере, но не на компьютере разработчика.

Мне все равно, будет ли база данных уничтожена.

Ответы [ 8 ]

3 голосов
/ 07 апреля 2010

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

По сути, вы не хотите связываться с живыми данными, и вы не хотите, чтобы у вас не было резервной копии на случай, если вы что-то испортите (и вы будете!).

1 голос
/ 07 апреля 2010

Используйте manage.py dumpdata > mydata.json, чтобы получить копию данных из вашей базы данных.

Перейдите на локальный компьютер, скопируйте mydata.json в подкаталог вашего приложения с именем fixtures, например. myapp/fixtures/mydata.json и делай:

manage.py syncdb # Set up an empty database
manage.py loaddata mydata.json

Ваша локальная база данных будет заполнена данными, и вы сможете протестировать их.

1 голос
/ 07 апреля 2010

Краткий ответ: нет.

Длинный ответ: вы не делаете, вы делаете копию производственной базы данных и запускаете ее там

0 голосов
/ 05 февраля 2013

Если ваша база данных поддерживает базы данных шаблонов, используйте производственную базу данных в качестве базы данных шаблонов. Убедитесь, что у вас есть доступ к базе данных Django.

Если вы используете PostgreSQL, вы можете легко сделать это, указав имя вашей производственной базы данных как POSTGIS_TEMPLATE (и использовать сервер PostGIS).

0 голосов
/ 03 сентября 2011

У меня есть как полный-на-медленный-django-test-db набор, так и сумасшедший набор тестов "быстрый запуск против производства", построенный из общего модуля тестирования. Я использую производственный пакет для проверки работоспособности моих изменений во время разработки и в качестве шага проверки фиксации на моей машине разработки. Модуль django suite выглядит следующим образом:

import django.test
import my_test_module
...
class MyTests(django.test.TestCase):
    def test_XXX(self):
        my_test_module.XXX(self)

Модуль производственного набора тестов использует пустое unittest и выглядит так:

import unittest
import my_test_module
class MyTests(unittest.TestCase):
    def test_XXX(self):
        my_test_module.XXX(self)
suite = unittest.TestLoader().loadTestsFromTestCase(MyTests)
unittest.TextTestRunner(verbosity=2).run(suite)

Тестовый модуль выглядит так:

def XXX(testcase):
    testcase.assertEquals('foo', 'bar')

Я запускаю чистую юнит-тестовую версию, подобную этой, поэтому в моих тестах в любом случае для них доступен ORM django:

% python manage.py shell < run_unit_tests

где run_unit_tests состоит из:

import path.to.production_module

Производственному модулю нужно немного отличаться от setUp () и tearDown () от версии django, и вы можете поместить туда любую необходимую очистку таблицы. Я также использую тестовый клиент django в общем тестовом модуле, имитируя класс тестового клиента:

class FakeDict(dict):
    """
    class that wraps dict and provides a getlist member
    used by the django view request unpacking code, used when
    passing in a FakeRequest (see below), only needed for those
    api entrypoints that have list parameters
    """
    def getlist(self, name):
        return [x for x in self.get(name)]

class FakeRequest(object):
    """
    an object mimicing the django request object passed in to views
    so we can test the api entrypoints from the developer unit test
    framework
    """
    user = get_test_user()
    GET={}
    POST={}

Вот пример функции тестового модуля, которая тестирует через клиента:

def XXX(testcase):
    if getattr(testcase, 'client', None) is None:
        req_dict = FakeDict()
    else:
        req_dict = {}
    req_dict['param'] = 'value'
    if getattr(testcase, 'client', None) is None:
        fake_req = FakeRequest()
        fake_req.POST = req_dict
        resp = view_function_to_test(fake_req)
    else:
        resp = testcase.client.post('/path/to/function_to_test/', req_dict)
    ...

Я обнаружил, что эта структура действительно хорошо работает, а суперскоростная производственная версия пакета значительно экономит время.

0 голосов
/ 07 апреля 2010

Если вы действительно не заботитесь об уничтожении БД, то ответ Марко на откат транзакции также является моим предпочтительным выбором.Вы также можете попробовать NdbUnit , но я лично не думаю, что дополнительный багаж, который он приносит, стоит выигрыша.

Как вы тестируете тестовый дБ сейчас?Под тестовой БД вы подразумеваете SQLite?

HTH,
Berryl

0 голосов
/ 07 апреля 2010

Первое, что нужно попробовать - вручную выполнить тестовый код в оболочке на рабочем сервере.

python manage.py shell

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

Если есть способ попросить django использовать стандартную базу данных, не создавая новую, я думаю, что вместо создания фиксатора, вы можете создать sqldump, который обычно будет гораздо меньшего размера.

0 голосов
/ 07 апреля 2010

Сделайте копию базы данных ... Это действительно хорошая практика !!

Просто выполните тест, вместо вызова commit, отката вызова в конце.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...