Здравствуйте, __SPIRIT__, Вы писали:

__S>Ни разу такое не видел. Можно как-то развернуть зачем это делается и почему, как выглядит и т.п.
Что именно? Сопротивление или бурчание?

Здравствуйте, Nikolay_Ch, Вы писали:

__S>>Ни разу такое не видел. Можно как-то развернуть зачем это делается и почему, как выглядит и т.п.
N_C>Что именно? Сопротивление или бурчание?

Вот эту фразу развернуть:

ИМХО сопротивление нововведениям происходит чаще всего не из-за возраста, а именно из-за возможности поконфликтовать с руководством

Здравствуйте, __SPIRIT__, Вы писали:

__S>Вот эту фразу развернуть:
__S>

__S>ИМХО сопротивление нововведениям происходит чаще всего не из-за возраста, а именно из-за возможности поконфликтовать с руководством

В своей скромной практике я не особо не встречал дифференциации сопротивляющихся нововведениям по возрасту, а вот воспринимающих нововведения через призму личных взаимоотношений с руководителем встречал.

Здравствуйте, Аноним, Вы писали:

А>Юнит-тесты — по определению автоматические, потому что они тестируют код без участия человека, автоматически. Неужели кто-то с этим не согласен?

Это утверждение не имеет отношения к исходному постингу. Да, автоматические, и что? Перефразирую: я говорю своим работникам, что мешок цемента надо везти на транспорте (а не пешком). С этим никто из них не спорит. А потом я спрашиваю: почему не на велосипеде привезли? А они мне: в данном конкретном случае велосипед не подходит. Хотя велосипед — вид транспорта, неужели с этим кто-то не согласен?

Кроме юнит-тестов есть другие АВТОМАТИЧЕСКИЕ, выполняемые ПОЛНОСТЬЮ без участия человека, тесты. И бывает так, что есть смысл потратить время на написание их, а не юнит-тестов. Если пишется, например, специализированный веб-сервер, есть смысл написать пачку тестов, которая бы генерировала n запросов в секунду, давала неправильно оформленные запросы и т.д. и т.п. Каждый случай, когда живой человек-тестер находит в таком сервере баг, может быть оформлен отдельным тестом, поскольку где тонко и порвалось, там и в следующий раз порвется (по тестировочной науке это называется regression testing: Common methods of regression testing include rerunning previously-completed tests and checking whether program behavior has changed and whether previously-fixed faults have re-emerged). Надо ли обкладывать тестами юниты (классы и функции) — бог весть. Ну можно, в последнюю очередь, когда тесты реальных сценариев написаны.

С пользой автоматического тестирования абстрактно, без деталей, спорить никто в здравом уме не будет, поскольку это из серии "вкалывают роботы, счастлив человек". Но использовать ли юнит-тест ИЛИ другой автоматический тест, а также, поддается ли конкретный кусок кода автоматическому тестированию вообще — зависит от ситуации. И ЕСТЬ ситуации, когда вообще от тестов (любых) один вред. Мой любимый пример: есть бэкграунд, на нем надо показать связанную с ним анимацию. Типа, как тетка в прогнозе погоды тыкает указкой по фону-битмапке, хотя его не видит. Анимацию дают делать двум программистам. Один здоровый на голову человек, другой — фанат юнит-тестов без головы. Начальника над ним нет, просто фанат. Первый пишет текстовый файл с координатами столбиком, зачитывает оттуда опорные точки, и анимирует изображение, используя кривые Безье (30 строк кода). Второй думает, как это можно протестировать юнит-тестами. Если картинка поменяется, а анимация нет, будет ведь баг! В результате, простую картинку в любом формате, понимаемом рендерером, превращает в фотошоповский файл, внутри которого в виде пути (path) должна хранится поточечная анимация, а к коду проекта добавляется импорт .psd. Проблемы, которые при этом решаются... а их нет. Ничто не мешает дизайнеру забыть обновить path, меняя layer. Только совесть очистить у любителя тестов. Новые проблемы: появляется СОТНИ строк кода, которые обеспечивают импорт, налагают новые условия на входной файл (типа имен объектов внутри), все это надо отдельно тестить, да плюс еще на билд-сервер ставить фотошоп для Automation. К счастью, первый программист был нанят мною, и свой код он написал, а второй ВСЕГО ЛИШЬ предложил свой безумный план, который я отверг. Если вы считаете, что он обосрал светлую идею юнит-тестирования, предложите свою.

В заключение: сам подход навязывания — извращенный. Вам что надо? Чтобы в релизе багов не было, или тесты для галочки? Если первое, программистов надо просто дрючить за баги, найденные ПОСЛЕ разработки, в восьмикратном размере — за найденные юзерами. И уж тут каждый сам для себя решит, каким образом ему свою задницу прикрыть. Если ему именно юнит-тесты помогут, он их с радостью начнет писать. А если толку от них ноль, пусть пишет другие тесты, по усмотрению.

Здравствуйте, michael_isu, Вы писали:

_>Здравствуйте, Аноним, Вы писали:

А>>Похоже, единственный способ — просто заставить, в приказном порядке без обсуждений.

_>Это не работает, т.к. люди, не понимающие как и зачем писать тесты, нормальных тестов не напишут, итого кроме проекта придется поддерживать тесты.

их в любом случае придётся поддерживать

Здравствуйте, Аноним, Вы писали:

А>Насколько я вижу, программистам бесполезно пытаться по-человечески объяснять преимущества автоматического тестирования, потому что они соглашаются, а потом все равно делают по-старому под предлогами "в данной конкретной задаче затруднительно применить юнит-тестирование" и "нет времени, сейчас сделаю так, а юнит-тесты когда-нибудь потом", и так каждый программист в каждой задаче. Таким образом, добровольное и осознанное внедрение юнит-тестов полностью провалилось.

А>Похоже, единственный способ — просто заставить, в приказном порядке без обсуждений.

А>Кстати, вопреки интуиции, на практике с программистами только такой способ очень часто и работает. Попробуй быть "хорошим начальником" — об тебя начнут вытирать ноги.

Начнем с того, что какую проблему вы хотите решить юнит тестами?

Здравствуйте, Аноним, Вы писали:

А>Похоже, единственный способ — просто заставить, в приказном порядке без обсуждений.

Да. И не забыть отвести на юнит-тесты некоторое время, которое, кстати, может быть больше, чем время самой разработки.

Здравствуйте, Аноним, Вы писали:

А>Соответственно, "автоматизация юнит-тестов" — это какая-то автоматизация второго порядка, видимо, когда юнит-тесты генерируются автоматически. Но я не это имел в виду.

А>Юнит-тесты — по определению автоматические, потому что они тестируют код без участия человека, автоматически. Неужели кто-то с этим не согласен?

Это терминологический конфликт плюс специфика перевода с английского на русский.

Прямой перевод английского "Unit" на русский язык даёт нам слово: "Блок". Чуть изогнутый перевод: "модуль". Но как ни крути, привернуть способ запуска сюда не получается. И блок, и модуль — это структурная характеристика тестируемого кода.

А вот автоматический тест — это тест, который запускается автоматически, без специальных усилий. Что он там тестирует — вопрос отдельный.

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

То есть мы запросто можем говорить об автоматическом интеграционном тестировании или автоматическом модульном тестировании, равно как и о ручном тестировании модулей, или ручном интеграционном тестировании.

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

А>Юнит-тестирование является подмножеством автоматического, или, если хотите, автоматизированного тестирования (хотя, получается, что последний термин менее точный, потому что в юнит-тестах никакого участия человека в процессе тестирования нет и никогда не было).

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

Здравствуйте, Аноним, Вы писали:

А>Мой любимый пример: [...]

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

А>Вам что надо? Чтобы в релизе багов не было, или тесты для галочки? Если первое, программистов надо просто дрючить за баги, найденные ПОСЛЕ разработки, в восьмикратном размере — за найденные юзерами.

Уже пробовал? И как, получилось?

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

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

Есть такая фирма, называется "Контур".
Так вот, мне как-то говорили, что если программиста работая над проектом создает много багов или что-то в этом роде. В общем пишет не работающий код, то его на один день ставят в отдел поддержки.
В некоторых фирмах программисты так же занимаются поддержкой.
Следствие — прямая мотивация писать хорошо продокументированный и понятный код.
Быть может вам подойдет. Хотя я на это смотрю скептически.

Здравствуйте, Аноним, Вы писали:

А>Насколько я вижу, программистам бесполезно пытаться по-человечески объяснять преимущества автоматического тестирования, потому что они соглашаются, а потом все равно делают по-старому под предлогами "в данной конкретной задаче затруднительно применить юнит-тестирование" и "нет времени, сейчас сделаю так, а юнит-тесты когда-нибудь потом", и так каждый программист в каждой задаче. Таким образом, добровольное и осознанное внедрение юнит-тестов полностью провалилось.

Думаю, что ещё не дошли ещё до нужного уровня понимания.
Может стоит провести какие то курсы.
Но, наверное, человек сам должен дойти до этого.

А>Похоже, единственный способ — просто заставить, в приказном порядке без обсуждений.

...и при первом удобном случае все похерят эту идею

А>Кстати, вопреки интуиции, на практике с программистами только такой способ очень часто и работает. Попробуй быть "хорошим начальником" — об тебя начнут вытирать ноги.

Здравствуйте, maxkar, Вы писали:

M>Здравствуйте, Ionich, Вы писали:

I>>Общий вывод такой: Как правило сейчас требуют результат от разработчика — работающий код по истечении выделенного на это рабочее время (которое оплачивается). Если попробовать изменить подход — оплачивать качество работающего кода с чётко заданными критериями (по времени работы, по занимаемым ресурсам, конечно же отказоустойчивость как критерий отсутвия багов), естественно в оценке трудозатрет изначально иметь в виду написание юнит-тестов исходя из задачи и вышеоговоренных критериев.

Шаг 1 — отделение тестов от проекта:
Не пишите юнит-тесты, если нет времени или желания. Просто для каждого класса, пакета (пространства имён) или чего-нибудь ещё сразу создавайте файлы с юнит-тестами в которых можно начать их писать. Разработчики всё равно так или иначе запускают тесты, только они их пишут где-нибудь в коде, а потом когда те срабатывают — стирают. Получается зряшная работа. Для начала нужно отказаться от замусоривания тестами кода проекта. Если захотелось написать какой-то тест, нужно использовать для этого отдельные уже приготовленные файлы.

Шаг 2 — программирование по контракту:
Может быть со временем захочется проверять контракты на работу методов системы и всего класса. Предусловия, постусловия, инварианты станут не пустым звуком.

Шаг 3 — требования:
А есть ещё всякие требования, их тоже можно проверять. Так что если в силу увеличения квалификации появится возможность системного анализа, то можно будет и его потихоньку добавлять.

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

Здравствуйте, Аноним, Вы писали:

А>Что можно сделать:
А>1. Нанять коуча который промоет проггерам мозги и заставит любить юнит-тесты. Если проггеры молодые это прокатит на ура.
А>2. Внедрить измерение тестового покрытия и в приказном порядке ввести формальные метрики: для новых задач 60% для старого кода 30%. Без соответствия метрикам задачу не принимать и денег за нее не платить. Будут бухтеть, конечно, но где-то за год привыкнут и даже нормальные тесты со временем писать научатся.

Мозги тут менеджерам нужно промывать, а не программистом. Чего только менеджеры не предложат от осознания собственной бестолковости.
Ты понимаешь, что только что своим постом расписался в собственной профессиональной никчемности как менеджера. Начиная от фраз "промоет проггерам мозги" и заканчивая предложением ввести метрики.
Ну будут программисты писать тесты ради метрики.
В результате, и проект будет стоить дороже, и качество останется тем же, если не хуже.
Отличный результат работы эффективного менеджера.

Здравствуйте, MaximVK, Вы писали:

А>>2. Без соответствия метрикам задачу не принимать и денег за нее не платить. Будут бухтеть, конечно, но где-то за год привыкнут и даже нормальные тесты со временем писать научатся.

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

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

[lol]
А не платить программистам деньги очень правильное решение. Через год они разумеется всё ещё будут впахивать на благодетеля и никуда не уйдут. Нужно ещё ввести нормы выработки, тогда появятся программисты-стахановцы. За день они своими отбойными молотками будут производить в несколько раз больше кода. И ещё надо всех замотивировать, чтобы глаза горящие, а вместо сердца пламенный мотор.

[/lol]

Здравствуйте, Аноним, Вы писали:

А>Похоже, единственный способ — просто заставить, в приказном порядке без обсуждений.

Очень недальновидно это.

Если цель именно внедрить юнит тесты, то есть след. варианты. все опробованы:

— Парное программирование или так называемый программерский пинг-понг. Берешь задачу, берешь любого программиста и садитесь за одну клавиатуру. Сначала ты пишешь тест, а второй должен написать код, проходящий этот тест. Затем он пишет тест, а ты код.
— Ввести такую практику: если всплывает бага, то сначала пишется тест на нее (не обязательно юнит), а только затем она фиксится

Ну и вообще, здесь только собственный пример может помочь. Ну или пример какого-то лида. Все эти "выполним план по покрытию" и "ну пишите тесты, ведь это так классно" — не канают.

А>Кстати, вопреки интуиции, на практике с программистами только такой способ очень часто и работает. Попробуй быть "хорошим начальником" — об тебя начнут вытирать ноги.

Опираясь на собственный опыт — я бы посоветовал начать с малого и не задаваясь целью обеспечить 100% покрытие, начать самому писать тесты только там, где это понятно, удобно и кратко сделать.
Где это занимает времени не больше, чем писать\исправлять тестируемый метод.
Потом, достаточно быстро, появится понимание того, как создавать код так, чтоб его было легче тестировать.
А потом, может быть, придет понимание, как научить и показать всю прелесть подхода другим.

Здравствуйте, Аноним, Вы писали:

А>Кстати, вопреки интуиции, на практике с программистами только такой способ очень часто и работает. Попробуй быть "хорошим начальником" — об тебя начнут вытирать ноги.

А можешь дать свое определение "хорошего начальника"? Кстати, "менеджер проекта" != "начальник".