Post #234

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