UT: если не верить на слово...

Бычно, реально, нет времени UT реализовывать. Лог спасает.

я не скажу за исследования, не встречал [бо не искал], но в одном достаточно большом проекте, в котором посчастливилось поучаствовать, всевозможные юнит тесты и регрессии составляли примерно половину - если не две трети - всего написанного когда. целый фреймворк. что в сумме составляло примерно 500Mb исходников в CVS :) и да, тесты чрезвычайно помогали при разработке. точнее, при релизе а тем более, скажем, смене платформы [RHEL4->RHEL5]. я слабо себе представляю, как можно было бы держать на плаву такой проект не имея грамотной системы тестирования.

// wbr

> нет времени UT реализовывать.
Вот это-то мне хорошо знакомо. Интересует как раз вопрос, можно ли исследованиями доказать, что стратегически это "нет времени" обходится дороже. Или хотя бы в каких случаях это так, а в каких действительно можно пережить и без UT

UT нужны. Но обычно это вырождается в то, что обновляются они раз в год, причём человеком, которого занять больше нечем (стажёром, например). В итоге все их преимущества уходят в трубу.

Есил пишешь тесты сразу с кодом --- они и пишутся легче и в тестировании помогают. А если тесты пишутся потом, потому что нет времени --- они только в тягость.

P.S. Что-то тебя на философию в последнее время потянуло.

> Но обычно это вырождается в то, что обновляются они раз в год
А если в конторе есть tinderbox, который ПОСТОЯННО крутит эти тесты из системы контроля версий - и рассылает грязные ругательства, если код сломан?

> Есил пишешь тесты сразу с кодом --- они и пишутся легче и в тестировании помогают.
Адназначна! Но даже сразу с кодом они таки занимают некоторое время. А тут менеджер с выпученными глазами прибегает... В общем, хочется внятной и честной адвокатуры UT. Желательно, без агитации за XP ;)

> P.S. Что-то тебя на философию в последнее время потянуло.
Да, я тоже заметил. Старею:)

> Адназначна! Но даже сразу с кодом они таки занимают некоторое время. А тут менеджер с выпученными глазами прибегает... В общем, хочется внятной и честной адвокатуры UT. Желательно, без агитации за XP ;)

попробуй заверифицировать хотя бы на соответствие внутренним стандартам систему, состоящую из сотен компонентов. причём каждый из которых сам по себе может быть достаточно нетривиальной вещью а связь между ними далеко нелинейной. без развитой автоматизированной системы тестов - застрелишься. и каждый релиз будет на уровне "ну, с богом!". а если одной-двух анти саксес стори по факту достаточно, чтобы серьезно подмочить репутацию системы и в том числе больно ударить по карману...

// wbr

>> Но обычно это вырождается в то, что обновляются они раз в год
> А если в конторе есть tinderbox, который ПОСТОЯННО крутит эти тесты из системы контроля версий - и рассылает грязные ругательства, если код сломан?
В таких случаях настраиваются фильтры в почтовике :)

>> Есил пишешь тесты сразу с кодом --- они и пишутся легче и в тестировании помогают.
> Адназначна! Но даже сразу с кодом они таки занимают некоторое время. А тут менеджер с выпученными глазами прибегает... В общем, хочется внятной и честной адвокатуры UT. Желательно, без агитации за XP ;)
"Я ж всё равно эти тесты прогоняю, когда тестирую свои изменения, так почему бы и не записать их и не гонять постоянно?" --- как-то так.

> хотя бы на соответствие внутренним стандартам систему, состоящую из сотен компонентов

Не надо горячиться! Я говорю про UT. ST и IT - это совсем другое дело. Тестировать связи между компонентами - это отдельный геморрой, тут можно отдельный топик открывать;) Но совсем не у всех создаются системы из сотен компонент, и у менеджеров бывает иллюзия, что неформальные ST/IT плюс тестирование заказчиком - типа, достаточно. А что поддержка этого дела вызывает депрессию у людей - who fsking cares?...

> В таких случаях настраиваются фильтры в почтовике :)
Обнаружение подобного фильтра - мгновенное увольнение;)

> "Я ж всё равно эти тесты прогоняю, когда тестирую свои изменения, так почему бы и не записать их и не гонять постоянно?" --- как-то так.
Потому что запись и формализация стоят денег, требуют времени, вокруг них надо построить хотя бы минимальный процесс...

> ST и IT - это совсем другое дело.

ST и IT - это просто UT для компонентов верхнего уровня :)

Автоматизация и формализация UT - вполне по реализуемо практически для любой системы. В случае ST это часто очень нетривиально. А IT вообще почти невозможно (=беспредельно дорого).

Я к тому, что если они понимают необходимость ST и IT, нужно внушать им мысль, что UT - это такой ST, но находит больше багов (за счет того, что UT больше).

Они б и ST выкинули, но заказчик не поймет;) И у них есть иллюзия, что в ST найдут все, что реально важно.

Я, как очень опытный разработчик, могу сказать, что писать проэкт надо с исключительно с набора тестов. Они и только они помогут понять, что в конечном счете вы хотите изобразить и максимально уточнить архитектуру и спецификации. Причем процесс это итеративный и наборы тестов должны эволюционировать вместе с проэктом.

черт, я думал Unreal Tournament открыли... а тут глупости какието...

Это начало лекции по XP?;) Да, я согласен - но я хочу доказательств того, что стратегически именно так жить правильно.

Неужто никто не видал каких-нибудь исследований по этому поводу?

Дык кризис. Все жестко экономят, в основном на тестерах. Стафф резко сокращается. Мне вот тоже недавно пришлось отдать 3 тестеров и одминчека за одну секретаршу.

Я не очень верю в UT если юнит-тесты разработчик для своих юнитов пишет сам. Ведь если он в своём коде не предусмотрел некоторую ситуацию и при возникновении этой ситуации код ведёт себя неправильно, то и в тестах он эту ситуацию не предусмотрит, соответственно ошибка отловлена не будет.

> Ведь если он в своём коде не предусмотрел некоторую ситуацию и при возникновении этой ситуации код ведёт себя неправильно, то и в тестах он эту ситуацию не предусмотрит, соответственно ошибка отловлена не будет.

На это есть всякие способы оценки ковераджа. Зато единожды отловленная бага уже никогда не повторится. Это очень важный бенефит.

> Я, как очень опытный разработчик, могу сказать, что писать проэкт надо с исключительно с набора тестов. Они и только они помогут понять, что в конечном счете вы хотите изобразить и максимально уточнить архитектуру и спецификации.

Только это не UT - UT полностью автоматизировано, а ты пишешь про набор сценариев и их тестов, которые могут выполнятся с помощью алгоритма со студентом.

Идея UT конечно классная - но IMHO зависит от прикладной области, и профита. Тест так или иначе надо выполнять - только есть один небольшой момент - в полноценном UT тебе надо будет сделать систему больше и сложнее, чем то что ты проверяешь - будет ли профит - тебе решать :)

P.S. и будет ли профит твоему клиенту, за всё это платить

На мой взгляд, без UT в больших проектах жопа. В моем, порядка 500 тыр строк. Уже жопа. Очень жалею что не реализовано ни строчки.
UT нужен и все. Всегда. Это как отдельные операторы на новой строке писать.
Ну не знаю. Если бы проект начать запово, то обязательно бы. Хотя кода в 2 раза больше получается. Оно того стоит.

> будет ли профит - тебе решать
Решать-то хочется из опыта умудренных мудростью мудрых. Публикаций хочу!

> UT нужен и все. Всегда. Это как отдельные операторы на новой строке писать.
Бездоказательно. Отдельный оператор на новой строчке не стоит ничего. А UT стоят денег. Поэтому нужны основания.

> Я, как очень опытный разработчик, могу сказать, что писать проэкт надо с исключительно с набора тестов. Они и только они помогут понять, что в конечном счете вы хотите изобразить и максимально уточнить архитектуру и спецификации. Причем процесс это итеративный и наборы тестов должны эволюционировать вместе с проэктом.

черт, свершилось! а я уже и не чаял, что свершится. наконец то я узнал, кто же есть на самом деле Sun-ch: опытный разработчик. могу лишь снять шляпу перед его скромностью, что он столь долго умалчивал сей знаменательный факт, заставляя думать окружающий черти знает что.

// wbr

А какие основания? Любой приличный софт обязан включаеть набор тестов, которые нужны для того, чтобы убедиться, что сборка и инсталляция пакета в данной среде выполнена корректно.

> Решать-то хочется из опыта умудренных мудростью мудрых. Публикаций хочу!

http://www.joelonsoftware.com/items/2009/01/31.html

Чтобы убедиться в корректности сборки и инсталляции, нужен не UT. Это другие тесты.

Спасибо, для начала неплохо;)

> Адназначна! Но даже сразу с кодом они таки занимают некоторое время. А тут менеджер с выпученными глазами прибегает...

а попробуй хронометраж сделать. 1) Вот сижу пишу код. Вот прибежал менеджер "всё пропало, шеф, всё пропало". Вот доковырялся до причины. Вот дописал фикс и починил. 2) Вот сижу пишу тест. -"-
а потом с цифрами ему предьявить: % приходов менеджера в 1-м и в 2-м случае, и среднее время исправления ошибки (по коммитам можно скриптом посчитать).

Это безусловно очень правильная идея. Но я не думаю, что Вы первый до нее догадались. Неужто никто не поделился статистикой из тех, кто уже?

http://serg.telecom.lth.se/research/publications/docs/396_IEEE06UnitTestRunes...
ftp://ftp.ncsu.edu/pub/unity/lockers/ftp/csc_anon/tech/2008/TR-2008-22.pdf
http://www.jmir.org/2007/2/e8

/me дал ссылку товарищу

он ответил следующее:

какой-то странный вопрос
из серии "чистить ли зубы"

IHMO UT имеет смысл, когда народ постоянно былутся XP/Agile и соответственно постоянно что-то рефакторит.
Т.е. завист от производственного цикла.

Если UT нет в проекте изначально, лучше не пытаться его туда впихнуть на позднее. Будет только хуже. Хотя бывают и исключения.

на самом деле, для маленьких проектов на одного-трёх человек, когда объём информации вполне возможно держать в голове и люди действительно хорошо знают сделанную ими систему, можно обойтись и без жестко выделенного юнит-тестирования.

с другой стороны, всё равно система даже если она небольшая как то но бьётся на компоненты, которые разрабатываются итеративно. не бывает так, чтобы бац! и всё вдруг готово. соотв. в процессе разработки того или иного компонента хочется проверить его работоспособность. а поскольку конечная система ещё не готова, пишутся небольшие специализированные тесты, отладочные утилиты, и тд и тп. хотя этот процесс и нельзя наверное назвать гордым словом "целенаправленное тестирование" бо какой то чёткой методологии скорее всего нет и тесты пишутся по мере возникновения необходимости. которая может возникнуть а может и нет :)

// wbr

thanks a bunch!

Давно ли товарищ в индустрии? Во многих ли компаниях работал? ;)

Вопрос в том, стОит ли его туда впихивать вначале. И при каких условиях.

Тут, как бы, тема заключается в том, что если даже и использовать, то, именно, с самого начала разработки проекта, иначе это может стать серьёзной помехой развитию проекта.. Хотя, опять же.. В зависимости от.. То есть, имеются и исключения.. Ну, о том, что следует придерживаться определённых правил, в любом случае.. я, как бы, даже и упоминать не имею желания.

> я, как бы, даже и упоминать не имею желания.
Поздно. Упомянуто.

Перевезенцева Е. С., перелогиньтесь.

Я, лично, не видел ни одго проекта, где это съэкономило-бы время и соответственно деньги.
В лучшем случе они выходят 1:1 с проектом, где вместо юниттестов писали спеки изначально.
Хотя может я изз-за некоторой специфики работы просто сталкиваюсь с нудачными применениями.

IMHO, если планируется XP/Agile(польза которых для меня сомнительна) и коллектив имеет опыт проектов с применением UT то, теоретически, от UT есть польза.

От нормального бизнесаналиста+архитекта пользы больше.

> IMHO, если планируется XP/Agile
Нет, так далеко мы не заходим.

> где это съэкономило-бы время и соответственно деньги
Сколько времени уходит на change requests/bugfixes/...? Как иначе убедиться, что фикс не сломал то, что работало раньше?

> От нормального бизнесаналиста+архитекта пользы больше.
Ну это ж разные уровни!

>> IMHO, если планируется XP/Agile
>Нет, так далеко мы не заходим.
Ну, много рефакторинга, хотя обычто он нужен, когда не нормальных спков или нормального архитекта.

>Сколько времени уходит на change requests/bugfixes/...?
зависит от того, сколько у клиента денег :)
В смысле наколько качественное и глобальное решение ему нужно.
Обычно, так как нет денег, то приходится отрезать всё что можно и здесь UT может помочь, но не гарантировано.

Как я уже писал первопричиной того, что применяется UT это если большинство в тиме знает как не переюниттестить и не недоюниттестить.

>Как иначе убедиться, что фикс не сломал то, что работало раньше?
regression testing 'n' user acceptance testing?

Да, специфика моей работы, что я в большинстве случев поднимаю мёртвые проекты. Т.е. прихожу когда уже "всё пропало".

Соответсвенно, проект с нуля делаю только если пропало настолько, что проще написать заново, чем пытаться оживить то, что сотворили ранее.

Проект в которм UT больше чем кода и чинить приходится в основном UT ничуть не приятнее просто бездарно сделанного проекта а может быть дажи и хуже.
Что намекает.

> Как я уже писал первопричиной того, что применяется UT это если большинство в тиме знает как не переюниттестить и не недоюниттестить.

Это не причина. Это пререк;)

> regression testing 'n' user acceptance testing?
Я не понимаю, как сделать первое вне UT. А второе это уже из жизни IT все больше..

> Т.е. прихожу когда уже "всё пропало".
Да, это специфично. Как было сказано, внедрение UT в проекты, где их изначально не было - очень дорогое удовольствие, практически неоправданное

>Это не причина. Это пререк;)
Да, конечно же :)

>> regression testing 'n' user acceptance testing?
>Я не понимаю, как сделать первое вне UT
:)
Regression Testing не имеет отношения к UT
Нанимается сеньор тестер. Он пишет скрипты(на английском) и остальные тестеры кликают по кнопкам, проверяя что всё работает как написано в скрипте.

Никакого UT :)

>Да, это специфично.
Зато сколько фана!

>внедрение UT в проекты, где их изначально не было - очень дорогое удовольствие, практически неоправданное
Но починка тех где его применение было доведено до абсурда - дело тоже неприятное. А выбросить нельзя, так как наверху об этой фиче уже доложили и деньги съели.

ps
Толку от меня болше не будет, после того как я предострёг :)