Лучший способ изменить значение «настройки» из теста Python?

Question

Я впервые пишу юнит-тесты на Python для приложения Django. Я столкнулся с проблемой. Чтобы протестировать конкретную часть функциональности, мне нужно изменить значение одного из параметров приложения. Вот моя первая попытка:

def test_in_list(self):
    mango.settings.META_LISTS = ('tags',)
    tags = Document(filepath).meta['tags']
    self.assertEqual(tags, [u'Markdown', u'Django', u'Mango'])

Я пытаюсь изменить значение META_LISTS так, чтобы при создании объекта Document использовалось новое значение. Соответствующий импорт ...

# tests.py
from mango.models import Document
import mango.settings

# models.py
from mango.settings import *

Если я правильно понял, поскольку models.py уже импортировал имена из mango.settings, изменение значения META_LISTS в mango.settings не изменит значение META_LISTS в mango.models.

Возможно - вероятно, даже - что я поступаю об этом совершенно неправильно. Как правильно изменить значение такой «настройки» в тестовом примере?

Редактировать: Я не упомянул, что файл models.py содержит ванильные классы Python, а не модели Django. Мне обязательно нужно переименовать этот файл!

Answer 1

В models.py используйте import mango.settings. Затем вы можете установить переменную в своем тестовом коде так же, как и любую другую:

mango.settings.foo = 'bar'

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

Но это не сработает, если вы используете from mango.settings import *, поскольку это выражение копирует значения из модуля в текущее пространство имен.

Answer 2

Для изменения настроек в TestCases я использую измененную версию этого фрагмента http://www.djangosnippets.org/snippets/1011/

Вот моя модификация этого фрагмента http://github.com/dominno/django-moderation/blob/master/src/moderation/tests/utils/testsettingsmanager.py

Затем я создаю файл с моими настройками теста и затем использую (пример из моего проекта):

class SerializationTestCase(SettingsTestCase):
    fixtures = ['test_users.json', 'test_moderation.json']
    test_settings = 'moderation.tests.settings.generic'

    def setUp(self):
        self.user = User.objects.get(username='moderator')
        self.profile = UserProfile.objects.get(user__username='moderator')

    def test_serialize_of_object(self):
        """Test if object is propertly serialized to json"""

        json_field = SerializedObjectField()

        self.assertEqual(json_field._serialize(self.profile),
                    '[{"pk": 1, "model": "test_app.userprofile", "fields": '\
                    '{"url": "http://www.google.com", "user": 1, '\
                    '"description": "Old description"}}]',
                         )

Он будет отслеживать исходные настройки и позволит легко вернуть их обратно после завершения теста.

Answer 3

Будет ли этот параметр использоваться во время тестов?В этом случае одним из решений будет создание файла настроек для тестирования.Например, добавьте settings_for_tests.py.

# settings_for_tests.py
from settings import * # Get everything from default settings file.

# Override just what is required.
META_LISTS = ('tags',)

и затем запустите свои тесты следующим образом:

$ python ./manage.py test mango --settings=settings_for_tests

Это обеспечит создание моделей в базе данных теста с использованием настроек тестане настройки по умолчанию.

Если вы делаете это, имеет смысл переместить файлы настроек в каталог.Например,

project
  |
  |_ settings
  |    |
  |    |_ __init__.py # Contains merely from settings import *
  |    |_ settings.py
  |    |_ settings_for_tests.py
  |
  |_ apps
       |

Answer 4

Существует более простой способ сделать это.

Использовать несколько файлов настроек - каждый под надлежащим контролем конфигурации.

Мы делаем это.

1. У нас есть мастер settings модуль с настройками «всегда».Промежуточное программное обеспечение, установленные приложения, другие параметры, уникальные для наших приложений.

2. У нас есть настройки «подкласса», которые (а) импортируют основные настройки, а затем (б) вводят специфичные для платформы (или стадии)-конкретные или специфичные для клиента) настройки.Здесь наш путь к файлу Windows изолирован.Плюс расположение статических медиафайлов.Плюс пользовательские пути к шаблонам и т. Д.

3. Мы разбиваем наши тестовые сценарии на несколько частей.«По умолчанию» tests.py выполняет базовые тесты моделей, форм и представлений, которые должны работать на всех платформах, на всех этапах разработки (dev, test, qa и т. Д.) И для всех клиентов.

4. У нас есть отдельные скрипты модульного тестирования, которые требуют специальных настроек для особо сложных приборов. Они не включены в tests.py и не запускаются автоматически. Они требуют явного вызова утилит Django для настройки и тестирования сред.

См. http://docs.djangoproject.com/en/1.2/topics/testing/#module-django.test.utils

---

, как вы бы порекомендовали проверить глупую функцию, которая возвращает "привет", когда конкретный параметр верен, и "до свидания", когдаfalsy

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

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

У вас должна быть функция, которая принимает settings.SOME_SETTING в качестве аргумента, поэтомучто вы можете протестировать его как отдельное устройство, не беспокоясь о том, чтобы все окружение было правильным.Вы должны верить, что среда и среда действительно работают.