Еще 2 преимущества автотестов
“Да ладно, в следующий раз напишу тесты, вроде все работает” — каждый ловил себя на такой мысли. Бывает, мы успокаиваем себя тем, что проект маленький, шанс его уронить невелик, и можно не переживать. Но такая вероятность есть всегда, и с ростом проекта она только увеличивается.
В реальных проектах могут быть тысячи строк с десятками классов, которые взаимодействуют друг с другом. И представьте, что ваша текущая задача требует модифицировать всего пару строк в классе. Ноо… От этого класса зависят ещё три. А от этих трёх еще по три… И в итоге ваши 2 строчки могут уронить всю систему. Как избежать этого?
Можно потратить пару дней на то, чтобы придумать и проверить все сценарии, при которых проект может упасть или отработать некорректно — но это точно будут не самые интересные пару дней. Скорее всего вы как разработчик предпочли бы писать код и катить новые фичи, а не изучать легаси-куски системы.
... вот опять бы была кнопка, на которую жмешь и проверяешь: все ли корректно работает.
Автотесты — та самая кнопка.
В одном посте тему автотестов не обхватить, но мы добавим аргументов "за" тесты, чтобы замотивировать вас в них разобраться.
С очевидными плюсами тестов многие уже знакомы и согласны: тесты снижают вероятность появления нелепых багов (например, при рефакторинге) и экономят время на проверки. В этом же посте мы поделимся еще парой не самых очевидных преимуществ.
Тесты — это документация
Ведь на какие вопросы обычно отвечает документация:
- как выглядят базовые сценарии работы приложения?
- что делает функция? — в идеале с примерами
- как собрать инстанс класса?
- на какие куски кода я повлияю, если изменю вот этот метод?
- хочу красивую страничку с поясняющими картинками и ссылками на ютуб, чтобы как для тупых
Если ответственно подойти к процессу тестирования, то все пункты кроме последнего можно удовлетворить. Причем зачастую тесты в реальных проектах — единственная документация и в них полезно заглядывать, когда вы с знакомитесь с проектом.
Тесты контролируют сложность кода
С течением времени наш когда-то понятный прозрачный проект превращается в клубок грязи, который очень тяжело поддерживать.
Почти всегда такой клубок просто невозможно тестировать — и это хорошая новость. Ведь если вы понимаете, что на какую-то логику очень сложно написать тест, значит с большой вероятностью вы написали плохоподдерживаемый код и его нужно рефакторить.
P.S. не надо ждать момента, когда проект разросся и его стало тяжело править, пишите тесты со старта! Иначе рискуете уйти в крайность "уже слишком поздно, это невозможно тестировать...".
Какие еще полезные последствия тесты принесли вам? Пишите в комментариях! А в следующих постах расскажем про типичные ошибки при написании тестов и о том, как их избежать.
Если вы хотите научиться писать тесты, приходите на нашу программу CVRocket. На ней мы учим приводить в порядок эксперименты, ускорять модели, оборачивать их в веб-сервис, настраивать ci/cd — и все это при поддержке опытных инженеров.
#заметки @deep_school
“Да ладно, в следующий раз напишу тесты, вроде все работает” — каждый ловил себя на такой мысли. Бывает, мы успокаиваем себя тем, что проект маленький, шанс его уронить невелик, и можно не переживать. Но такая вероятность есть всегда, и с ростом проекта она только увеличивается.
В реальных проектах могут быть тысячи строк с десятками классов, которые взаимодействуют друг с другом. И представьте, что ваша текущая задача требует модифицировать всего пару строк в классе. Ноо… От этого класса зависят ещё три. А от этих трёх еще по три… И в итоге ваши 2 строчки могут уронить всю систему. Как избежать этого?
Можно потратить пару дней на то, чтобы придумать и проверить все сценарии, при которых проект может упасть или отработать некорректно — но это точно будут не самые интересные пару дней. Скорее всего вы как разработчик предпочли бы писать код и катить новые фичи, а не изучать легаси-куски системы.
... вот опять бы была кнопка, на которую жмешь и проверяешь: все ли корректно работает.
Автотесты — та самая кнопка.
В одном посте тему автотестов не обхватить, но мы добавим аргументов "за" тесты, чтобы замотивировать вас в них разобраться.
С очевидными плюсами тестов многие уже знакомы и согласны: тесты снижают вероятность появления нелепых багов (например, при рефакторинге) и экономят время на проверки. В этом же посте мы поделимся еще парой не самых очевидных преимуществ.
Тесты — это документация
Ведь на какие вопросы обычно отвечает документация:
- как выглядят базовые сценарии работы приложения?
- что делает функция? — в идеале с примерами
- как собрать инстанс класса?
- на какие куски кода я повлияю, если изменю вот этот метод?
- хочу красивую страничку с поясняющими картинками и ссылками на ютуб, чтобы как для тупых
Если ответственно подойти к процессу тестирования, то все пункты кроме последнего можно удовлетворить. Причем зачастую тесты в реальных проектах — единственная документация и в них полезно заглядывать, когда вы с знакомитесь с проектом.
Тесты контролируют сложность кода
С течением времени наш когда-то понятный прозрачный проект превращается в клубок грязи, который очень тяжело поддерживать.
Почти всегда такой клубок просто невозможно тестировать — и это хорошая новость. Ведь если вы понимаете, что на какую-то логику очень сложно написать тест, значит с большой вероятностью вы написали плохоподдерживаемый код и его нужно рефакторить.
P.S. не надо ждать момента, когда проект разросся и его стало тяжело править, пишите тесты со старта! Иначе рискуете уйти в крайность "уже слишком поздно, это невозможно тестировать...".
Какие еще полезные последствия тесты принесли вам? Пишите в комментариях! А в следующих постах расскажем про типичные ошибки при написании тестов и о том, как их избежать.
Если вы хотите научиться писать тесты, приходите на нашу программу CVRocket. На ней мы учим приводить в порядок эксперименты, ускорять модели, оборачивать их в веб-сервис, настраивать ci/cd — и все это при поддержке опытных инженеров.
#заметки @deep_school