Никому не казалось, что UT (ака модульные тесты) на которые задрачивают многие, (большинство) на самом деле серъёзно тормозят процесс развития системы, при том, что не способны выявлять какие либо ошибки, отличные от простейших и примитивных, которые и без тестов видны любому, у кого имеется хоть капля опыта. Вот написал чувак подсистему, накидал тысячу тестов (функций UT). Прошло полгода, понадобилось изменить фнукционал подсистемы, серъёзно изменить. 80% всех тестов, естественно, после внесения изменений, не проходят, нужно переписывать UT в соответствии с новыми реалиями, затрачивая времени в два раза больше, чем на модификацию самой подсистемы. Через три месяца потребовалось снова изменить/дополнить функционал модуля-снова возня с переделкой тестов etc... Так зачем они вообще тогда там упёрлись? Функционал проверяется функциональными тестами, сложные ошибки отлично выявляются ручным тестированием, поиск самих ошибок и багов-трассой и дебаггером. UT представляются порождением какого-то жутко слоупочного разума, ставшего модой. Что думаете по этому поводу?
Здравствуйте, smeeld, Вы писали: S>Что думаете по этому поводу?
Это просто дублирование кода. Относись к этому спокойнее — если заказчик хочет платить в два раза больше за ту же работу, пусть платит.
На надежность софта это влияет слабо: 60% ошибок это ненаписанный код (который физически невозможно покрыть тестами ввиду его отсутствия) и еще половина ошибок дублируется в тестах.
Всё, что нас не убивает, ещё горько об этом пожалеет.
Модульные тесты — это отличный инструмент для многих задач. К примеру мы его использовали для постоянной автоматической проверки работы сложного алгоритма, существующего внутри приложения. Алгоритму на вход подавались некие не тривиальные данные (несколько десятков вариантов) и проверялся выход. На мой взгляд без UT разрабатывать подобные системы очень не удобно.
Единственная проблема UT в том, что некоторые "фанаты" начинают пихать их не только для подобных задач, но и вообще куда угодно. Возможно это пошло от динамических языков, где UT помимо вышеописанной задачи, применяются ещё и для в каком-то смысле замены статической типизации. И такое в принципе тоже можно понять (хотя если уж хочется таких проверок, то наверное лучше просто выбрать другой язык).
Но вот когда в статически типизированных языках начитают применять UT для всякой ерунды — это уже действительно некое заболевание из "фанатской" области... )))
Думаю крамольную мысль: большинство ошибок, выявленных юнит-тестами, это ошибки в самих юнит-тестах, что превращает их в пустую трату времени.
Бывают, конечно, случаи, когда ЮТ реально нужны. Это когда пишешь какую-нибудь хитрую решалку, какой-нибудь кастомный велосипед.
Здравствуйте, smeeld, Вы писали:
S>Вот написал чувак подсистему, накидал тысячу тестов (функций UT). Прошло полгода, понадобилось изменить фнукционал подсистемы, серъёзно изменить. 80% всех тестов, естественно, после внесения изменений, не проходят, нужно переписывать UT в соответствии с новыми реалиями, затрачивая времени в два раза больше, чем на модификацию самой подсистемы.
Не то, что бы я был такой уж фанат поголовного покрытия кода тестами, но...
Я предполагаю, что подсистема довольно большая (иначе нет проблемы), и что ее кто-то использует (иначе, опять же, нет проблемы). И что в команде более одного разработчика.
Вот он что, сидел себе тихо в углу полгода, а потом молча выкатил новый вариант этой подсистемы, а остальные полгода сидели и ждали, пока новая подсистема появится?
В реальной жизни изменения стараются делать инкрементально, сохраняя, насколько это возможно, совместимость со старыми интерфейсами, хотя бы временно, на переходной период. Это позволяет начать использовать новый код сразу по мере его появления. В результате, к тому времени, когда подсистема переписана, большая часть ее не только протестирована, но и проверена в бою и признана годной. Этот процесс протекает относительно безболезненно.
А если устраивать революцию, это получается, что сначала надо ждать чувака, который ничего не делает, кроме как код с нуля переписывает, а потом вся команда будет стоять на ушах, его новую версию интегрировать, а потом еще полгода ничего не будет работать, потому что выкатили кучу кода, который никто никогда в реальной жизни не проверял, и из него повылезет куча багов. Так, в общем, обычно не делают.
Здравствуйте, smeeld, Вы писали:
S>Никому не казалось, что UT (ака модульные тесты)
Ты про тестирование геттеров и сеетеров? Ну да бессмысленно, а unit tests очень полезная штука, особенно когда пишешь код под разные платформы — проблемы специфичные для конкретной платформы выявляются моментально.
>Алгоритму на вход подавались некие не тривиальные данные (несколько десятков вариантов) и проверялся выход. На мой взгляд без UT разрабатывать подобные системы очень не удобно.
Полностью поддерживаю, но хотелось бы прояснить про терминологию:
вот эти несколько десятков вариантов, особенно, именно нетривиальных данных, это точно "юнит"-тесты?
Здравствуйте, smeeld, Вы писали:
S>Никому не казалось, что UT (ака модульные тесты) на которые задрачивают многие, (большинство) на самом деле серъёзно тормозят процесс развития системы, ..... Так зачем они вообще тогда там упёрлись?
Здравствуйте, smeeld, Вы писали:
S>Никому не казалось, что UT (ака модульные тесты) на которые задрачивают многие, (большинство) на самом деле серъёзно тормозят процесс развития системы, при том, что не способны выявлять какие либо ошибки, отличные от простейших и примитивных, которые и без тестов видны любому, у кого имеется хоть капля опыта. Вот написал чувак подсистему, накидал тысячу тестов (функций UT). Прошло полгода, понадобилось изменить фнукционал подсистемы, серъёзно изменить. 80% всех тестов, естественно, после внесения изменений, не проходят, нужно переписывать UT в соответствии с новыми реалиями, затрачивая времени в два раза больше, чем на модификацию самой подсистемы. Через три месяца потребовалось снова изменить/дополнить функционал модуля-снова возня с переделкой тестов etc... Так зачем они вообще тогда там упёрлись? Функционал проверяется функциональными тестами, сложные ошибки отлично выявляются ручным тестированием, поиск самих ошибок и багов-трассой и дебаггером. UT представляются порождением какого-то жутко слоупочного разума, ставшего модой. Что думаете по этому поводу?
Я ровно по этой причине от них и отказался. Когда разрабатываешь систему в одиночку, писать ют не имеет смысли. В два раза больше времени потратится, а потом после рефакторинга придется половину выкинуть.
Я бы применял эту практику там, где над проектом постоянно работает больше 1 человека. А еще хорошо новичкам давать задачу писать ют -- за одно и с кодовой базой познакомятся. Впрочем, я это же самое мнение здесь писал года 2 назад.
Здравствуйте, antropolog, Вы писали:
S>>Что думаете по этому поводу? A>Всё так. Рабочая максима — Write tests. Not too many. Mostly integration.
А потом ВНЕЗАПНО 10..15 часов
Проекты и код бывает очень разный. В некоторых случаях UT (МТ) — это то, что доктор прописал. Например, всякие прикладные алгоритмические библиотеки. Или если динамический ЯП. В других случаях МТ бесполезны чуть менее, чем полностью. Пример — интеграционные проекты, то есть проекты, сложность которых сосредоточена не в алгоритмах, а в сложном и непредсказуемом окружении. В этом случае нужны функциональные интеграционные тесты.
Здравствуйте, smeeld, Вы писали:
S> Прошло полгода, понадобилось изменить фнукционал подсистемы, серъёзно изменить. 80% всех тестов, естественно, после внесения изменений, не проходят, нужно переписывать
...нужно переписывать остальную систему, которая с этой системой интегрируется. Что вам тесты и показали.
Уже одно это может порой сэкономить пару мифических человеко-лет.
.
я практически уверен, что к этому ВНЕЗАПНО люди шли с бараньим упорством в течении нескольких лет. CI и время прогона надо холить и лелеять с самого начала. Но вопрос — как это связано с юнит-тестированием? Было бы 10..15 часов + 5..10 мин. юнит тесты, так лучше? То что юнит-тесты не могут быть заменой интеграционным, кагбе очевидно, надеюсь.
Зависит от задачи.
Если пишешь очередной опердень, то — да — на любое изменение бизнес логики надо править тесты, и их смысл становится не очень понятен.
А если разрабатываешь хитрую либу с хитрой математикой, то в этом случае тесты очень полезны.
. A>я практически уверен, что к этому ВНЕЗАПНО люди шли с бараньим упорством в течении нескольких лет. CI и время прогона надо холить и лелеять с самого начала. Но вопрос — как это связано с юнит-тестированием? Было бы 10..15 часов + 5..10 мин. юнит тесты, так лучше? То что юнит-тесты не могут быть заменой интеграционным, кагбе очевидно, надеюсь.
Время работы интеграционных тестов обычно контролировать гораздо сложнее. Если тебе надо развернуть виртуалку (а то и несколько), залить тестовые данные в СУБД (а то и несколько), запустить браузер (а то и несколько) и погонять под Selenium — то как ни крутись, в 5-10 мин не уложиться никак.
Цель юнит-тестов — обеспечивать качество кода достаточное для мержей development ветки. Т.е. юнит-тесты, работающие 5-10 минут (а лучше — меньше) прямо из IDE значительно уменьшат вероятность такого: "приводит к долгим часам, потерянным на отладку багов, которые принесла другая команда.".
А прохождение всех этих интеграционных тестов — обеспечивает production ready качество (на что уже позволительно потратить хоть неделю).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, smeeld, Вы писали:
s> Так зачем они вообще тогда там упёрлись? Функционал проверяется функциональными тестами, сложные ошибки отлично выявляются ручным тестированием, поиск самих ошибок и багов-трассой и дебаггером. UT представляются порождением какого-то жутко слоупочного разума, ставшего модой. Что думаете по этому поводу?
* Иногда подготовка релиза для функционального и интеграционного тестирования занимает сильно больше времени (и ресурсов) прогона юнит-тестов => отсутствие ut == потеря времени и денег.
* Проверка всех ветвей работы функциональным/ручным тестированием обычно сильно дольше проверки ut, т.к. там могут возникать дополнительные накладные расходы (например, расходы на установку сетевого соединения).
* Интеграционное и функциональное тестирование обычно не может проверить некоторые классы граничных условий (нехватка памяти, флапы сети и т.д.), которые вполне неплохо эмулируются mock-ами => ut это еще и культура разработки, которая накладывает отпечаток на архитектуру разрабатываемого ПО (и там не приходится переписывать 80% тестов, потому что каждый юнит тестируется максимально независимо от других).
Там тесты действительно нужны. Вручную там тестировать практически нереально — десятки компонентов на разных машинах / в разных докер-контейнерах, большой набор фич. То, что я хочу исправить — процесс, а не сами тесты. Чтоб не требовать полного прогона всех тестов на каждый чих.
