День 1340. #ЗаметкиНаПолях #Testing F.I.R.S.T. – Акроним для Хороших Тестов Аббревиатуры, особенно яркие, помогают нам запоминать важные вещи. FIRST – поможет запомнить, какими должны быть ваши юнит-тесты. 1. F - Fast (Быстрые) Не создавайте тесты, требующие много времени для настройки и запуска: в идеале вы должны иметь возможность выполнить весь набор тестов менее чем за минуту. Если модульные тесты занимают слишком много времени для выполнения, с ними должно быть что-то не так: - Вы пытаетесь получить доступ к удалённым источникам (реальные API, базы данных и т. д.). Их следует либо замокать, либо использовать в интеграционных или сквозных тестах. - Система слишком сложна для сборки - слишком много зависимостей. - Метод делает слишком много вещей. Разделите его на более мелкие. 2. I - Isolated (Изолированные) Методы тестов должны быть независимыми друг от друга. Обычно тесты исполняются в алфавитном порядке по названию (если отключено параллельное исполнение). Но в общем случае надеяться на это не следует. Создавайте новые экземпляры тестируемых объектов и воссоздавайте нужное состояние системы в каждом тесте. Так изменения в одном тесте не повлияют на другие. 3. R – Repeatable (Повторяемые) Это означает, что где бы и когда бы вы ни запускали тесты, они должны вести себя корректно. Поэтому вы должны удалить любую зависимость от файловой системы, текущей даты (дня недели) и так далее. Вынесите эти зависимости и используйте заглушки или моки для них. 4. S - Self-validating (Самопроверяющиеся) Тест должен выполнять операции и программно проверять результат. Если вы тестируете, что вы записали в файл, сам тест должен отвечать за проверку правильности своей работы. Если система генерирует и отправляет email, содержимое которого надо проверить, сделайте мок, который просто будет сохранять текст письма в переменную и проверять её. Никаких ручных операций выполнять не следует. Кроме того, тесты должны обеспечивать явную обратную связь: тест либо проходит, либо не проходит, никаких промежуточных результатов. 5. T – Thorough (Тщательные) Модульные тесты должны быть тщательными в том смысле, что они должны проверять как удачные, так и неудачные пути. Вы должны тестировать функции как с допустимыми, так и с недопустимыми входными данными, проверить, что будет, если во время выполнения возникнет исключение: правильно ли обрабатываются ошибки? В этом смысле очень помогают программы (расширения IDE), отслеживающие покрытие кода тестами. Общая цифра покрытия мало о чём говорит. Зато отметки напротив каждой строки кода, исполнялась ли она в тесте явно покажут вам, не забыли ли вы проверить какое-либо условие. Ведь помимо простых ветвлений через if, бывают и switch, и тернарные операторы, и сложные условия, и блоки catch, и т.п. В этом случае программа, отслеживающая покрытие кода тестами, отметит строку обычно зелёным, если она выполнилась в ходе теста, красным, если нет, или жёлтым, если выполнилась только часть условий в ветвлении. Источник: https://www.code4it.dev/cleancodetips/f-i-r-s-t-unit-tests