Обычно проверка кода проводится в несколько этапов.
Линтеры
В самом начале код проверяется на соответствие требованиям по оформлению. Принято оформлять код по PEP8.
Дополнительно может проводиться проверка аннотирования типов (type hints), её можно провести с помощью анализатора MyPy. В учебных проектах мы не проверяем, но это может практиковаться на вашем новом месте работы.
Проверка оформления и аннотирования типов занимает мало времени и легко проводится: для этого не нужна ни инфраструктура, ни специальные настройки — только исходный код.
Тесты
Этот процесс сложнее и дольше. Для тестирования потребуется правильная и полная установка и настройка всего приложения.Менеджеры любят coverage: там есть циферки, которые удобно показывать заказчикам на презентациях. Но даже coverage 100% всё равно не говорит, что вы молодец, а проект идеален.
Будьте гибче, тестируйте лишь то, что нужно для вашего приложения. Практический опыт показывает, что для качественной проверки проекта вполне достаточно 60-70% покрытия тестами.
Хозяйке на заметку: высокий процент покрытия не говорит об отсутствии ошибок ни в коде, ни в тестах. Это вымысел.
Code review
Это вишенка на торте. Живой квалифицированный программист (или команда программистов) анализирует код и принимает решение, готов ли он для добавления в основной репозиторий проекта.
Успешному прохождению код-ревью обычно сопутствует отправка сообщения LGTM, сокращения от looks good to me. А в Практикуме ревьюеры присылают специальную картинку (она вам знакома — вы уже не одно ревью прошли).
Качество тестов
В современных проектах на одну строку продуктового кода в среднем приходится две-три строки тестового кода.
Не относитесь к тестам как ко второсортному коду. Полагать, что принципы DRY, KISS, YAGNI и прочие правила — это для основного кода, а в тестах допустимо все — большая ошибка.
Тесты — такой же код. Разница только в том, что у тестов другая цель — обеспечить качество вашего приложения.
Признаки хороших тестов
Атомарность
Каждый тест проверяет только один логический фрагмент кода.Если не придерживаться этого правила, тесты будет сложно обновлять и дорабатывать.
Тестирование сложного сценария (например, подписки на новости) должно быть разделено на несколько частей; каждая часть должна тестироваться отдельно.
Независимость
Работа теста не должна зависеть от результатов работы других тестов или ждать ввода данных от пользователя.Тест должен использовать специально для него подготовленные данные — и никакие другие.
Вариативность
Тестируйте все варианты состояний (statements) и немножко больше. Проверяйте, что сущность работает ожидаемо на корректных данных и адекватно — при некорректных.
Неизбыточность
Тесты не должны перекрывать друг друга: не пишите одинаковые тесты несколько раз.
Читабельные имена
Название теста, как и название переменной — очень важно. В короткое слово нужно уместить как можно больше смысла. Название теста вы увидите в отчёте, оно будет светиться в редакторе кода.По названию теста вы должны получить представление о том, что же он проверяет и что в нём происходит. Стоит приложить усилия и подумать о том, как в название, составленное из трёх-четырёх коротких слов, уместить всю эту информацию.