Проверка кода и качество тестов в Django

Обычно проверка кода проводится в несколько этапов.

Линтеры

В самом начале код проверяется на соответствие требованиям по оформлению. Принято оформлять код по PEP8.

Дополнительно может проводиться проверка аннотирования типов (type hints), её можно провести с помощью анализатора MyPy. В учебных проектах мы не проверяем, но это может практиковаться на вашем новом месте работы.

Проверка оформления и аннотирования типов занимает мало времени и легко проводится: для этого не нужна ни инфраструктура, ни специальные настройки — только исходный код.

Тесты

Этот процесс сложнее и дольше. Для тестирования потребуется правильная и полная установка и настройка всего приложения.Менеджеры любят coverage: там есть циферки, которые удобно показывать заказчикам на презентациях. Но даже coverage 100% всё равно не говорит, что вы молодец, а проект идеален.

Будьте гибче, тестируйте лишь то, что нужно для вашего приложения. Практический опыт показывает, что для качественной проверки проекта вполне достаточно 60-70% покрытия тестами.

Хозяйке на заметку: высокий процент покрытия не говорит об отсутствии ошибок ни в коде, ни в тестах. Это вымысел.

Code review

Это вишенка на торте. Живой квалифицированный программист (или команда программистов) анализирует код и принимает решение, готов ли он для добавления в основной репозиторий проекта.

Успешному прохождению код-ревью обычно сопутствует отправка сообщения LGTM, сокращения от looks good to me. А в Практикуме ревьюеры присылают специальную картинку (она вам знакома — вы уже не одно ревью прошли).

Качество тестов

В современных проектах на одну строку продуктового кода в среднем приходится две-три строки тестового кода.

Не относитесь к тестам как ко второсортному коду. Полагать, что принципы DRY, KISS, YAGNI и прочие правила — это для основного кода, а в тестах допустимо все — большая ошибка.

Тесты — такой же код. Разница только в том, что у тестов другая цель — обеспечить качество вашего приложения.

Признаки хороших тестов

Атомарность

Каждый тест проверяет только один логический фрагмент кода.Если не придерживаться этого правила, тесты будет сложно обновлять и дорабатывать.

Тестирование сложного сценария (например, подписки на новости) должно быть разделено на несколько частей; каждая часть должна тестироваться отдельно.

Независимость

Работа теста не должна зависеть от результатов работы других тестов или ждать ввода данных от пользователя.Тест должен использовать специально для него подготовленные данные — и никакие другие.

Вариативность

Тестируйте все варианты состояний (statements) и немножко больше. Проверяйте, что сущность работает ожидаемо на корректных данных и адекватно — при некорректных.

Неизбыточность

Тесты не должны перекрывать друг друга: не пишите одинаковые тесты несколько раз.

Читабельные имена

Название теста, как и название переменной — очень важно. В короткое слово нужно уместить как можно больше смысла. Название теста вы увидите в отчёте, оно будет светиться в редакторе кода.По названию теста вы должны получить представление о том, что же он проверяет и что в нём происходит. Стоит приложить усилия и подумать о том, как в название, составленное из трёх-четырёх коротких слов, уместить всю эту информацию.



Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: