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

А>Не дай бог такого начальника, который путает автоматическое тестирование и юнит-тестирование, но всегда готов приказать.
ИМХО юнит-тестирование можно и нужно делать автоматизированным... Почему оно не может быть автоматизированным — для меня непонятно.

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

А>>По моему опыту больше всего проблем со старичками.
B>Это которым уже лет 25-26?
Скажем так — если человек имеет пять лет опыта, то в нынешних временах, когда специалистов не хватает, он уже считается старичком...
Хотя, ИМХО сопротивление нововведениям происходит чаще всего не из-за возраста, а именно из-за возможности поконфликтовать с руководством. Если есть возможность упираться рогом и саботировать решения руководителя — будут это делать и малые и старые...

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

А>>Не дай бог такого начальника, который путает автоматическое тестирование и юнит-тестирование, но всегда готов приказать.
N_C>ИМХО юнит-тестирование можно и нужно делать автоматизированным... Почему оно не может быть автоматизированным — для меня непонятно.

Это ортогональные понятия. Автоматизировать можно любые тесты — вплоть до UI.
Ну, всё равно что называть все мотоциклы ямахами, а всё на чём стоит шильдик ямахи — мотоциклами.

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

S>Это ортогональные понятия. Автоматизировать можно любые тесты — вплоть до UI.
S>Ну, всё равно что называть все мотоциклы ямахами, а всё на чём стоит шильдик ямахи — мотоциклами.
Тогда к чему придирки Анонима? И так понятно, что топикастер говорит про автоматизацию юнит-тестирования.

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

N_C>Тогда к чему придирки Анонима? И так понятно, что топикастер говорит про автоматизацию юнит-тестирования.

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

A_K>И почему же второе не является первым, господин параноик?

А вот обратное, вообще говоря, не верно.

B>Это которым уже лет 25-26?
Среди тех, кому за 30, такие броневики тоже попадаются.

M>...Но большая часть кода в проекте — это не алгоритмы, а достаточно тривиальные вещи. Которые имеют хорошую особенность — они либо работают, либо не работают (т.е. в них не бывает так, что в зависимости от положения луны код глючит). В этом случае приложение запускать все равно придется (ну не могу я без запуска и прогона приложения считать, что все работает), а тесты ничего не дадут.
Популярное, но ошибочное представление, что тривиальные вещи покрывать автотестами не нужно. На самом деле в большинстве случаев нужно: тесты не только проверяют код на отсутствие ошибок, но и фиксируют контракты, которые могут быть нарушены в будущем вследствие рефакторинга. Львиная доля багов в сколько-нибудь крупном проекте обнаруживается не в сложных алгоритмах, а в изначально очень простых фрагментах кода с большой историей. Если вы не пишете код для того, чтобы запустить один раз и выбросить, то покрывать тестами стоит наиболее возможный в рамках ваших ресурсных ограничений объем кода. Единственной уважительной причиной, по которой некоторые (но не все) тесты могут быть не написаны, является бюджет проекта.

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

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

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

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

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

A_K>>И почему же второе не является первым, господин параноик?

А>Да у вас, батенька, талант — задавая однострочный вопрос, сделать два неверных утверждения. В газету надо. Статьи писать.

слив засчитан

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

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

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

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

A_K>>>И почему же второе не является первым, господин параноик?

А>>Да у вас, батенька, талант — задавая однострочный вопрос, сделать два неверных утверждения. В газету надо. Статьи писать.

A_K>слив засчитан

Жизнь не жежешечка, ее школьными фразами не на@#$те.

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

I>Код-ревью внутри команды, это первое (на счет чтения кода) а далее автотесты и ручное тестирование тестировщиком. А вообще я изначально имел в виду именно те баги которые попадают уже в продукт, которые находят пользователи.

Вот ревью то как раз против этих багов и эффективно. Если программист не продумал какой-то сценарий, то он его не протестирует ни в юнит-тестах, ни в готовом продукте. А если заметил, то кто мешает проверить поведение в готовом продукте? В некоторых случаях это regression-баги (которые раньше были исправлены). Вот там — да, юнит-тесты помогают. Но в бизнесе большинство "багов" возникает потому, что кто-то когда-то не продумал какое-то взаимодействие. Ну и стоимость regression-бага нужно учитывать (и другие способы борьбы с ними). Вполне может иметь смысл заводить тесты именно в результате обнаруженных багов, а не превентивно.

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

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

N_C>>Тогда к чему придирки Анонима? И так понятно, что топикастер говорит про автоматизацию юнит-тестирования.
S>

Вам обоим все понятно, потому, что читаете с пятого на десятое. Вот уж тема для "Управления проектами": как научить взрослых мужиков читать? Мишн импосибл.

Цитирую:

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

Если бы ко мне пришли объяснять про преимущества автоматического тестирования, я бы тоже согласился. Да и как тут не согласиться, когда автоматизированные тесты прогоняются за ночь и реально помогают не остаться тем, чьи баги нашли в релизе? А потом, допустим, спросили бы меня — "Где юнит-тесты?",и я бы точно так же ответил: в данной конкретной задаче затруднительно применить юнит-тестирование. Разумеется, если бы в данной конкретной задаче было затруднительно применить юнит-тестирование. Начальник просто ... и не понимает, что кроме юнит-тестов можно (и нужно!) писать другие автоматизированные тесты. Я таких видел. Tool-boys. Научили богу молиться, в смысле, юнит-тестам, будут их пихать куда можно и нельзя. К счастью, только видел, но никогда с такими не работал, ни под, ни над, ни сбоку.

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

M>>...Но большая часть кода в проекте — это не алгоритмы, а достаточно тривиальные вещи. Которые имеют хорошую особенность — они либо работают, либо не работают (т.е. в них не бывает так, что в зависимости от положения луны код глючит). В этом случае приложение запускать все равно придется (ну не могу я без запуска и прогона приложения считать, что все работает), а тесты ничего не дадут.
B>Популярное, но ошибочное представление, что тривиальные вещи покрывать автотестами не нужно. На самом деле в большинстве случаев нужно: тесты не только проверяют код на отсутствие ошибок, но и фиксируют контракты, которые могут быть нарушены в будущем вследствие рефакторинга.

Да знаю я эти соображения. Возражения тоже будут стандартными.

Тесты — это не то место, где удобно фиксировать контракты. Контракты должны быть в первую очередь сформулированы текстом. В документации к классу/методу (и при этом будут доступны в IDE по-месту). Тесты — это то место, где проверяются контракты. Но очень часто я вижу призывы писать тесты (и тесты пишутся), а вот на вопрос о документации (тех самых явных контрактах) получаю отрицательный ответ.

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

Документация (явный текстовый контракт) позволяет отлавливать аномалии архитектуры. Либо метод принадлежит не тому классу (несогласованность общего контракта объекта и контракта метода), либо просто делает что-то не совсем логичное (к чему нельзя придумать описания на нужном уровне абстракции). Тесты это не ловят, они проверяют только поведение.

Слишком часто тесты фиксируют как раз не контракты, а конкретную реализацию. Явный и наглядный симптом — использование моков. Ну вот так получается, что сложно предоставить объекту именно "контракт" (т.е. интерфейс с правильным поведением во _всех_ возможных сценариях). Поэтому фиксируется то, как объект будет вызывать методы внутри. И на первом же изменении поведения без изменения контракта мы получим упавшие тесты.

Можно еще в рефакторингах усомниться. По-определению рефакторинг — это преобразование, не изменяющее функциональность программы. А у вас рефакторинги что-то поломать рискуют. Но, в общем то, мелочи это.

А вот более серьезная проблема, связанная с рефакторингами (точнее, реинжинирингом) — тесты катастрофически мешают рефакторингу. Если уж затевать рефакторинг, то нужно что-то существенное делать. В этом случае интерфейсы меняются. Иногда — довольно сильно. Ранее тестированные объекты исчезают полностью. Код сокращается. Это не гипотетические проблемы. Это практика. Видел я проекты, где много покрыто тестами, иначе "как же проверять корректность...". Оно еще и глючит при этом, не смотря на тесты. На это все смотрится с безраздельной грустью, затем начинается хирургия. Интерфейсы выпиливаются, обобщаются, сокращаются. По формальному интерфейсу (без всяких тестов) задаются вопросы "а что оно здесь делает и какое отношение к объекту имеет". В результате код сокращается и упрощается. Куча тестов перестает быть актуальной (потому что функциональность теперь общая, библиотечная или вообще оказалась не нужна). Тесты радостно выпиливаются. Вообще, уменьшившееся количество тестов (вместе с количеством кода и количеством багов) — это у меня стандартный вариант рефакторинга доставшегося legacy-продукта. Могу мастер-класс провести, если интересно.

B>Львиная доля багов в сколько-нибудь крупном проекте обнаруживается не в сложных алгоритмах, а в изначально очень простых фрагментах кода с большой историей.
Ну в общем то логично. Но...

Первый же вопрос — а почему в определенный момент не был затеян рефакторинг/повторная итерация разработки? Очень много ситуаций, когда баги лезут из-за накопившихся противоречий в бизнес-требованиях. При этом бизнес-требований нет. И членораздельных контрактов к фрагменту кода тоже нет. Поэтому программист правит код и считает, что контракт не изменился. Как видите, это отсутствие контрактов (есть и другие решения кроме тестов) и общий бардак.

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

На практике у меня другой подход к этой же проблеме. Любые крупные изменения — это переписывание, не правка кода! Т.е. мелочи можно править. Что-то более серьезное — проще пересобрать требования и собрать нужный компонент программы заново. Это не сложно. Размер стандартного компонента не больше одной-двух тысяч строк. В терминах проекта — это "модуль/библиотека", т.е. отдельная "сущность" со своими зависимостями от других частей проекта. 5 тысяч строк для такого компонента — это уже много и большая редкость. Если вдруг это безобразие начинает после правок глючить сильно, это первый признак того, что стоит задуматься о переписывании. Для инфраструктурных библиотек/библиотек нужного уровня такой подход не всегда подходит. В некоторых случаях можно допустить "параллельное" существование аналогов, там тоже проблем нет. В еще более редких случаях остается возможность переписывания с сохранением интерфейса. Вот там тесты вполне оправданы. И то, не всегда, а если облегчают отладку или возможны нетривиальные баги. Из мелких компонент вытекают совершенно особые требования к системе сборки, но это уже другая история (вполне решенная на моем локальном уровне).

Да, еще соображение. Общая архитектура все-таки важна. Вот скажите, нужно ли тестировать конфиги приложения? Ну там, что прописана боевая база вместо тестовой? Или что логи сохраняются в том каталоге, где они должны сохраняться? Это (особенно первое) ведь такие вопиющие баги, которые будут заметны практически сразу при запуске! Вот стоит их тестировать? Если да, то почему? А у меня большинство багов в программе именно такие. Первое же функциональное тестирование их отловит.

Кстати, о функциональном тестировании. Вот его то я как раз применяю часто. И вообще, почти тдд применяю. Только вместо юнит-тестов — функциональные. Потому что юнит-тесты на UI писать грустно (да и UI меняется иногда), а глазками это заметно и в инкрементальной манере делать удобно. Сборка проекта под это заточена (быстрая и инкрементальная). Почти все, что я изменяю, я знаю (и, соответственно, проверяю). Функциональное тестирование — не полное, только изменений (и потенциально сломавшихся мест). Перед релизом — более подробное. Ну могу закинуть еще тестерам задачу "могло сломаться вот это, при прогонах посмотрите внимательнее". Но это те случаи, где куча юнит-тестов посыпалась бы из-за изменения интерфейса тестируемых объектов.

B>Если вы не пишете код для того, чтобы запустить один раз и выбросить, то покрывать тестами стоит наиболее возможный в рамках ваших ресурсных ограничений объем кода. Единственной уважительной причиной, по которой некоторые (но не все) тесты могут быть не написаны, является бюджет проекта.

Я могу рулить бюджетом на разработку (т.е. определять сроки и требуемые подходы в программировании). В том числе и на тестирование. С этим проблем не возникает. Если по каким-то причинам программист пишет юнит-тесты, у меня претензий нет (и мешать я не буду). Если не пишет, а код работает — тоже. Специально выделять бюджет и требовать тестирования — не стану, зачем? В целом лучше тот же "бюджет" потратить на правку случано всплывших багов и переписывание "болот", а не на тесты. Ну и в процессе рефакторингов (если такой понадобится) сломавшиется тесты будут удалены без сожаления. Кстати, багов при таком подходе в production вооще единицы попадают. Вот хотелось бы какой-нибудь крупный проект в хронической стадии (горы багов), карт-бланш на изменения и методолгию и поправить его до состояния "все прекрасно работает, багов нет, изменения вносятся в три раза быстрее". На не слишком больших legacy-проектах проверялось. Работает .

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

А>Вам обоим все понятно, потому, что читаете с пятого на десятое. Вот уж тема для "Управления проектами": как научить взрослых мужиков читать? Мишн импосибл.
Зачем придираться к словам , когда уже действительно стало понятно, что он пишет про автоматизацию юнит-тестов, которые и пишет, собственно, разработчик?

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

А>>Вам обоим все понятно, потому, что читаете с пятого на десятое. Вот уж тема для "Управления проектами": как научить взрослых мужиков читать? Мишн импосибл.
N_C>Зачем придираться к словам , когда уже действительно стало понятно, что он пишет про автоматизацию юнит-тестов, которые и пишет, собственно, разработчик?

Что такое "автоматизация юнит-тестов"?

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

А>Что такое "автоматизация юнит-тестов"?

Я топик-стартер и я тоже не понял, что такое "автоматизация юнит-тестов".

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

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

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

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

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

А>>Что такое "автоматизация юнит-тестов"?
А>Я топик-стартер и я тоже не понял, что такое "автоматизация юнит-тестов".

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

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

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

Так что "юнит" — означает что именно тестируется, а "автоматический" как именно тест запускается. Не надо мешать тёплое с мягким.

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

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

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

N_C>Скажем так — если человек имеет пять лет опыта, то в нынешних временах, когда специалистов не хватает, он уже считается старичком...
N_C>Хотя, ИМХО сопротивление нововведениям происходит чаще всего не из-за возраста, а именно из-за возможности поконфликтовать с руководством. Если есть возможность упираться рогом и саботировать решения руководителя — будут это делать и малые и старые...

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