Фреймворк проверки

Фреймворк проверки это набор статических тестов для проверки проектов Django . Он обнаруживает распространенные проблемы и дает советы по их исправлению. Этот фреймворк расширяемый, поэтому вы можете легко добавлять свои собственные проверки.

Проверки могут быть вызваны явно через команду check. Проверки вызываются явно до большинства команд, включая runserver и migrate. По соображениям производительности, проверки не запускаются как часть стека WSGI, который используется при развертывании. Если необходимо выполнить проверки на сервере, на котором развертывается приложение, вызовите их явно, используя команду check.

Серьезные ошибки не позволят выполниться командам Django (таким как runserver). Незначительные проблемы будут выведены на консоль. Если Вы уже выявили причину предупреждения и хотите ее проигнорировать, Вы можете убрать определенные предупреждения, используя параметр SILENCED_SYSTEM_CHECKS в файле настроек проекта.

Полный список всех проверок, которые могут быть вызваны Django, можно найти в System check reference.

Создание собственных проверок

Фреймворк является гибким и позволяет создавать функции, выполняющие любые виды проверок, которые могут понадобиться. Далее представлен пример функции-заглушки для проверки:

from django.core.checks import Error, register

@register()
def example_check(app_configs, **kwargs):
    errors = []
    # ... your check logic here
    if check_failed:
        errors.append(
            Error(
                'an error',
                hint=None,
                obj=checked_object,
                id='myapp.E001',
            )
        )
    return errors

Проверяющая функция должна принимать app_configs в качестве аргумента; этот аргумент является списком приложений, которые должны быть проверены. Если None, то проверка будет запущена для всех установленных в проекте приложений. Аргумент **kwargs необходим для последующего расширения.

Сообщения

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

Предупреждения и ошибки вызванные проверочным методом должны быть экземплярами класса CheckMessage. Экземпляр CheckMessage содержит одну ошибку или предупреждение. Он также предоставляет контекст и советы применимые к сообщению. А также уникальный идентификатор, которой используется для фильтрации.

Идея очень похожа на сообщения message framework или logging framework. Тег level показывает уровень важности сообщения.

Также, существуют вспомогательные вспомогательные функции, позволяющие создавать сообщения со стандартными уровнями. При использовании этих классов Вы можете пропускать аргумент level , т.к. он вытекает из названия.

Регистрация и маркировка проверок

Ваша функция проверки должна быть зарегистрирована в системном реестре проверок. Проверка должна быть зарегистрирована в файле, который загружается, когда загружается Ваше приложение; например, AppConfig.ready().

register(*tags)(function)

Вы можете передать столько тегов register сколько хотите, для того чтобы пометить свою проверку. Помеченные проверки очень полезны, т.к. позволяют запускать только определенную группу проверок. Например, для регистрации проверки на совместимость, Вы можете сделать следующий вызов:

from django.core.checks import register, Tags

@register(Tags.compatibility)
def my_check(app_configs, **kwargs):
    # ... perform compatibility checks and collect errors
    return errors
Добавлено в Django 1.8.

Вы можете регистрировать “deployment checks” , которые уместны только для настроек сервера:

@register(Tags.security, deploy=True)
def my_check(app_configs, **kwargs):
    ...

Эти проверки будут запускаться если опция --deploy передана в команду check

Вы можете использовать register как функцию, а не как декоратор, передавая вызываемый объект (обычно функцию) как первый аргумент в register.

Код ниже эквивалентен коду выше:

def my_check(app_configs, **kwargs):
    ...
register(my_check, Tags.security, deploy=True)
Изменено в Django 1.8:

Была добавлена возможность использовать регистр как функцию

Проверки полей, моделей и менеджеров

В некоторых случаях Вам не нужно регистрировать проверочную функцию, можете просто дополнить существующую регистрацию.

Поля, модели и менеджеры моделей выполняют метод check(), который уже зарегистрирован в фреймворке проверок. Если Вы хотите добавить дополнительные проверки, вы можете расширить реализацию базового класса, выполняя любые дополнительные проверки, которые Вам нужны, и добавляя любые сообщения к тем, которые генерируются базовым классом. Рекомендуется использовать отдельные методы для каждой проверки.

Рассмотрим пример, в котором Вы реализуете настраиваемое поле с именем RangedIntegerField. Это поле добавляет аргументы min и max к конструктору IntegerField. Вы можете захотеть добавить проверку, чтобы убедиться, что пользователь предоставляет минимальное значение, которое меньше или равно максимальному значению. Следующий фрагмент кода показывает, как можно выполнить эту проверку:

from django.core import checks
from django.db import models

class RangedIntegerField(models.IntegerField):
    def __init__(self, min=None, max=None, **kwargs):
        super(RangedIntegerField, self).__init__(**kwargs)
        self.min = min
        self.max = max

    def check(self, **kwargs):
        # Call the superclass
        errors = super(RangedIntegerField, self).check(**kwargs)

        # Do some custom checks and add messages to `errors`:
        errors.extend(self._check_min_max_values(**kwargs))

        # Return all errors and warnings
        return errors

    def _check_min_max_values(self, **kwargs):
        if (self.min is not None and
                self.max is not None and
                self.min > self.max):
            return [
                checks.Error(
                    'min greater than max.',
                    hint='Decrease min or increase max.',
                    obj=self,
                    id='myapp.E001',
                )
            ]
        # When no error, return an empty list
        return []

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

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

class MyModel(models.Model):
    @classmethod
    def check(cls, **kwargs):
        errors = super(MyModel, cls).check(**kwargs)
        # ... your own checks ...
        return errors

Написание тестов

Сообщения можно сравнивать. Это позволяет легко писать тесты:

from django.core.checks import Error
errors = checked_object.check()
expected_errors = [
    Error(
        'an error',
        hint=None,
        obj=checked_object,
        id='myapp.E001',
    )
]
self.assertEqual(errors, expected_errors)
« previous | up | next »