Тестирование семантики кода

Одной из практик тестирования является написание тестов по уже найденным ошибкам, чтобы исключить их в будущем. Но что делать, если ошибка не специфична для конкретной логической сущности, а может встретиться в любом месте?

Писать для каждого модуля одинаковые тесты — не самая вдохновляющая идея, тем более, о них ещё помнить надо. В некоторых случаях тест можно написать не для проверки поведения программы, а для проверки непосредственно её кода. Этакий семантический pep-8, если хотите.

В коде «Сказки» уже давно прописалось несколько таких тестов, собранных в файле test_code.py . О них и расскажу, для иллюстрации идеи.

Контроль импортов

Тест проверяет все импорты в проекте по списку разрешённых к использованию модулей. Очень помогает отслеживать артефакты всяческих экспериментов и рефакторингов. Кроме того напоминает исправлять настройки деплоя при изменении списка.

Контроль описания моделей Django

Некоторые параметры по-умолчанию бывают скорее вредны, чем полезны. Например, для ForeignKey в моделях Django по-умолчанию устанавливается удаление объектов по цепочке ссылок. Если вдруг об этом забыть, то при особо удачном стечении обстоятельств можно распрощаться с целостностью базы в продакшне.

Собственно, после похожего случая и появилось требование явного указания поведения при удалении для каждого ForeignKey.

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

Контроль способа получения и конструирования объектов

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

Все проверки не требуют заумных анализов AST и делаются обычным grep-ом.