• 3.1
  • 5.0
  • 6.1
  • Версия документации: 3.2

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

Фреймворк проверки это набор статических тестов для проверки проектов 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='A hint.',
                obj=checked_object,
                id='myapp.E001',
            )
        )
    return errors

Функция проверки должна принимать аргумент app_configs; этот аргумент представляет собой список приложений, которые следует проверить. Если указано значение «Нет», проверка должна выполняться для всех установленных приложений в проекте.

Проверка получит аргумент ключевого слова databases. Это список псевдонимов баз данных, соединения которых можно использовать для проверки конфигурации уровня базы данных. Если databases имеет значение 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

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

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

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

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

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

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

Field, model, manager, and database checks

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

Fields, models, model managers, and database backends all implement a check() method that is already registered with the check framework. If you want to add extra checks, you can extend the implementation on the base class, perform any extra checks you need, and append any messages to those generated by the base class. It’s recommended that you delegate each check to separate methods.

Рассмотрим пример, в котором Вы реализуете настраиваемое поле с именем 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().__init__(**kwargs)
        self.min = min
        self.max = max

    def check(self, **kwargs):
        # Call the superclass
        errors = super().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().check(**kwargs)
        # ... your own checks ...
        return errors

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

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

from django.core.checks import Error
errors = checked_object.check()
expected_errors = [
    Error(
        'an error',
        hint='A hint.',
        obj=checked_object,
        id='myapp.E001',
    )
]
self.assertEqual(errors, expected_errors)
Back to Top