Как сделать так, чтобы тестовый фреймворк django читался из реальной базы данных? - PullRequest
1 голос
/ 14 июня 2010

Я понимаю, что здесь есть похожий вопрос, но у него другой подход: у меня есть приложение django, которое выполняет запросы к данным, индексированным с помощью djapian ;Я хотел бы написать модульные тесты для поискового компонента этого приложения, и, очевидно, мне понадобится модуль настроек django и все соединения с активной базой данных, так что тестовый прогон, предоставляемый django, кажется идеальным. однако , среда тестирования django создает фиктивную базу данных, и я не хотел бы выгружать все свои данные в осветитель и затем индексировать их (тесты заняли бы навсегда !);

Мои данные не подвергаются риску, потому что тесты будут только считывать из базы данных, так как же этого достичь?- Я новичок во всем этом модульном тестировании, поэтому решение о написании нового тестового прогона Я читал в этом похожем вопросе не немного меня просветляет, по крайней мере, без некоторых подробностей

1 Ответ

2 голосов
/ 14 июня 2010

Читая тестовые примеры для djapian, я обнаружил кое-что действительно интересное: эти ребята используют метод setUp для класса TestCase: они создают объект, а затем используют метод обновления для индексатора, поэтому у них фактически есть документ для Ищите и способ написания тестов для контролируемых запросов! Для любопытных метод выглядит примерно так:

def setUp(self):
    p = Person.objects.create(name="Alex")

    for i in range(self.num_entries):
        Entry.objects.create(author=p, title="Entry with number %s" % i, text="foobar " * i)

    Entry.indexer.update()

Я думаю, что это подойдет, но мы должны помнить, что я тестирую небольшую поисковую систему здесь, так что это решение может быть простым выходом; Я не могу выдвинуть возражение, поэтому, если у вас, ребята, есть ответ, который поможет определить стратегию для тестирования такого рода веб-приложений в python в целом, это более чем приветствуется!

-Я думаю, что пока что остановлюсь на чем-то подобном (я хотел также проверить задержку запросов с полностью заполненной базой данных, но я думаю, что мог бы сделать это позже с помощью стендовых тестов в Funkload )

РЕДАКТИРОВАТЬ : Хорошо, чтобы быть верным решению для всех, кто заинтересовался, я столкнулся с другой проблемой: индексом xapian (как указано в комментарии). Чтобы решить эту проблему, я создал тестовый прогон по умолчанию, который изменил производственный индекс xapian для тестового индекса (меньшего, созданного с помощью сценария управления). Этот бегун довольно прост:

def custom_run_tests(test_labels, verbosity=1, interactive=True, extra_tests=[]):
    """Set the test indices"""
    settings.CATEGORY_CLASSIFIER_DATA = settings.TEST_CLASSIFIER_DATA    
    return run_tests(test_labels, verbosity, interactive, extra_tests)

И, чтобы использовать его, я просто добавил параметр:

TEST_RUNNER = 'search.tests.custom_run_tests'

Я отказался от вышеупомянутого подхода (создание документов в setUp) по соображениям производительности и читабельности: для тестирования базы данных мне потребовалось приличное количество документов с некоторым текстом (параграф или два), поэтому я в итоге создал прибор для этого (я использовал команду управления, которая создала документы в реальной базе данных, сериализовала их - записала их в файл - и затем удалила их). Так что, в конце концов, я вообще не читал с живого БД и вместо этого использовал тестовые таблицы, созданные с помощью довольно хакерского скрипта и собственного бегуна, и это было не так сложно:)

...