День 1194. #Testing Стоимость Кода Сегодняшний пост посвящён долгосрочным последствиям наших решений в процессе разработки программного обеспечения. Вопрос Простые однострочные свойства слишком тривиальны. Стоит ли их тестировать? Ведь в крупных или долгосрочных проектах кто-то может изменить их. Правильно ли предполагать, что их поведение никогда не изменится? Написать тест для них просто и займёт всего минуту. Разве уверенность в том, что никто случайно не сломает ваш код, подправив сеттеры и геттеры, не оправдывает написание чрезвычайно простых модульных тестов? Этот вопрос стоит разделить его на две части. 1. Правильно ли предположить, что поведение «однострочников» никогда не изменится? Нет необходимости это предполагать. Вы можете протестировать этот код, как только он станет достаточно сложным. Именно здесь становятся полезными инструменты покрытия кода. Покрытие кода - недостаточный показатель для определения качества ваших тестов. Но эти метрики всё же полезны в некоторых сценариях. Один из них — видеть, какие части вашего кода тестируются, а какие нет. Инструменты анализа покрытия кода позволяют увидеть добавление сложности (например, ветвления) в эти простые свойства. И вы заметите, что часть этой сложности не проверена. 2. Долгосрочная и краткосрочная стоимость кода Написание модульных тестов для этих однострочников тривиально и занимает всего минуту для каждого. Написать такие тесты действительно легко. Но это не главная проблема. Стоимость здесь состоит из двух частей: - Написание такого теста - Поддержание его на протяжении всего жизненного цикла проекта И вторая часть гораздо важнее первой. Написание кода — это одноразовое действие, вам нужно сделать это только один раз. С другой стороны, чтение и сопровождение кода — непрерывный процесс. Затраты на этот процесс со временем увеличиваются. Рассмотрим все действия, которые становятся более затратными по мере добавления новых тестов: - Рефакторинг тестов при рефакторинге тестируемого кода - Запуск дополнительных тестов при каждом изменении кода - Обработка ложных срабатываний - Затраты времени на чтение тестов, когда вы пытаетесь понять, как ведет себя тестируемый код Если это кажется слишком трудоёмким – это потому, что так оно и есть. Следовательно, вы должны уделять очень пристальное внимание тому, какие тесты вы добавляете в свой набор тестов. Лучше вообще не писать тест, чем писать малоценный тест, даже если сам этот тест простой. Обратите внимание, что это правило верно для всего вашего кода, а не только для тестов. Вы читаете код гораздо чаще, чем пишете его, поэтому весь ваш код должен быть оптимизирован для чтения, а не для написания. Источник: khorikov.org/posts/2…-of-code