Как мотивировать сотрудников писать юнит-тесты? [закрыто]

Мы работаем над крупным продуктом, который выпускается около 5 лет. Кодовая база ... эээ ... работает. Не очень хорошо, но это работает. Новые функции добавляются в производство и тестируются с небольшим контролем качества. Исправлены ошибки и т. Д. Но никто, кроме меня, не пишет юнит-тесты. Никто не использует возможности «отслеживания» ошибок путем написания модульных тестов, чтобы гарантировать, что эта специальная ошибка (контрольный пример) никогда больше не повторится.

Я разговаривал с руководством. Я разговаривал с разработчиками. Я разговаривал со всеми в этой компании. Все говорят: «Да, мы должны написать больше юнит-тестов!» Это было около года назад. С тех пор я принудительно ввел предварительный анализ кода ( Gerrit ) и непрерывную интеграцию ( Jenkins ).

Я провел несколько встреч о юнит-тестах и ​​показал преимущества написания юнит-тестов. Но никто не заинтересован.

Q1: Как я могу мотивировать моих коллег по написанию юнит-тестов?

Q2: Как мне оставаться мотивированным, чтобы я следовал стандартам качества моего личного кода? (Иногда это действительно расстраивает!)

PS: некоторые неприятные факты (достигнутые за 1 год):

• Всего юнит-тестов: 1693
• Всего «пример юнит-тестов»: около 50
• Сделано мной: 1521

Изменить: я ожидаю слишком много? Это мое первое рабочее место, и я стараюсь изо всех сил.

Изменить 2: На основе всех ответов я составил небольшой контрольный список для себя. Я поговорил с двумя разработчиками наедине, и у нас был хороший и честный разговор.

Один из них сказал мне, как сказал Теластин , что ему действительно неудобны юнит-тесты. Он сказал, что хотел бы быть «более профессиональным», но ему нужен кикстарт. Он также сказал, что наша юнит-тестовая встреча со всеми разработчиками (около 9-11) была хорошей, но это было слишком людно. Мех. Некоторые критики для меня, но я буду учиться на этом. (см. ответы ниже, обсуждая встречи tdd kata!)

Другой сказал, что он не заинтересован в написании юнит-тестов. Он думает, что его работа достаточно хороша для его зарплаты. Он не хочет вкладывать больше усилий. У меня не было слов. Типичный 9-5 "рабочий".

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

Спасибо за ваши отличные ответы (пока!) И вашу поддержку. Я очень ценю это! Я многому научился, большое спасибо!

Я заметил, что говорить о TDD вряд ли работает. Людям нравится видеть необработанные результаты . Утверждение, что «написание тестов сократит время разработки» , скорее всего, верно, но этого может быть недостаточно, чтобы кого-то убедить.

Я был в подобном положении (ну, не так плохо, как у вас), и это как-то разрешилось, когда люди начали работать над моим кодом (примечание: мой код был модульным тестированием, другие не так уж и много). Когда что-то перестало работать, естественным продолжением после местного расследования было выяснить, в чем причина . Потом мы сели, запустили юнит-тесты и увидели, что случилось. Если тесты проходили, большую часть времени были проблемы с новым, непроверенным кодом. Если нет, то тесты обычно могли определить проблему (или, по крайней мере, указать нам правильное направление). Мы исправили ошибку, тесты снова начались, все были счастливы.

Короче говоря, выяснилось несколько подобных ситуаций, и еще 2 разработчика стали энтузиастами TDD / тестирования (еще есть кое-что еще, но это выглядит многообещающе).

Что касается советов, вы можете попробовать с TDD ката; простая задача для реализации с использованием подхода «сначала тест», а не тестов . В зависимости от сложности задачи, не тестовый подход обычно должен быть медленнее, особенно с добавочными необходимыми изменениями:

• Струнный калькулятор Роя
• Банк OCR

Редактировать : комментарий OP заставил меня понять, что в его распоряжении есть еще более сильный аргумент - регрессия или ошибки . Подобные ситуации являются прекрасными примерами, демонстрирующими, насколько полезными могут быть юнит-тесты. Людям нравятся числа - как я уже сказал, сказать, что «модульное тестирование - это хорошо», может быть неубедительно, но размещение данных, как показано ниже, наверняка будет:

• время, потраченное на реализацию функции (тесты не были написаны; я предполагаю, что это часто случалось, поэтому найти такой пример должно быть относительно легко)
• расчетное время для реализации функции с помощью TDD (или даже тестов после захода на посадку; не имеет значения - важно наличие модульных тестов)
• время, потраченное на исправление ошибки в непроверенном и проверенном коде

Одна вещь, о которой следует предупредить (эта миграция очевидна, но стоит отметить): предвзятость результатов - убедитесь, что вы не выбрали пример, в котором единственным способом определения ошибки с помощью теста было написать тест для этой ошибки. Обычно никто не знает, что ошибка будет возникать заранее, но соблазнительно сказать: «Если бы у нас был тест на Х, то этот баг был бы тривиален - легко найти выигрышную тактику для войны после ее окончания».

Результатом этих примеров должен быть простой вопрос - если бы вы могли потратить x-часы на разработку функции Y, зачем настаивать на том, чтобы сделать это в 2x ?

Сначала вы должны знать, почему они не пишут тесты.

Тесные графики разработки часто являются причиной, но вы говорите, что у вас этого нет.

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

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

Еще одна сильная возможность заключается в том, что они действительно не видят никакой ценности для дополнительной работы, даже если они на словах высказывают идею.

Итак, как вы справляетесь с различными причинами?

Причина первая проста, показать им пример того, как это экономит время разработки.

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

Причина 3 - тренировка, а не просто показ. Заставьте их написать тесты в учебном классе.

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

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

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

Я бы начал с демонстрации преимуществ TDD. Попробуйте продемонстрировать преимущества модульного тестирования.

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

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

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

Хорошие ссылки для дальнейшего чтения:

• Почему вы должны написать модульные тесты
• Видимость мотивации и модульное тестирование
• Искусство юнит-тестирования, по словам Роя Ошерова

http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first

Я думаю, что добавил эту ссылку в статью Джеффа Этвуда некоторое время назад [править: да, вот она] . Старый, но актуальный. Благодаря этим и другим преимуществам, которые несомненно будут изложены в других ответах, ваши программисты должны быть в состоянии мотивировать себя ! Это позволит им работать более эффективно и тем самым упростить их работу. Кто этого не хочет?

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

Это похоже на большой пример привести пример .

Есть два неотъемлемых аспекта человеческой природы, с которыми вы боретесь:

• Творческие люди не любят процесс.
• Большинству людей не нравятся внешние негативные суждения об их качестве.

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

• Люди подражают поведению лучших сотрудников

Если лучшие сотрудники используют TDD, и он работает, процесс будет расширяться. Если они этого не сделают, это не так. Если вам нужно кого-то убедить, это 1 или 2 лучших сотрудника.

Спросите их.

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

Это не может (часто не так) вопрос простой мотивации. Они могут забыть о них. Они могут чувствовать нехватку времени. Они могут не знать, как писать хорошие тесты. Они могут подумать, что вы настолько хороши, что им не нужно это делать. Знание первопричины поможет вам лучше решить проблему.

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

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

Второй крупный продавец - цикл QA. До запуска TDD в моей компании мы будем выпускать новые релизы в QA для тестирования каждую неделю. Они будут создавать кучу ошибок из этого выпуска, мы исправим эти ошибки и запустим еще один выпуск. Повторите до конца. Первый проект, который мы сделали TDD, не потребовал отсылки в QA, пока несколько недель спустя. И количество найденных ошибок было очень, очень мало. 10% по сравнению с аналогичным проектом. У вас есть какой-нибудь способ собрать статистику для вашей команды?

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

Наконец, покажите им, как они смогут с уверенностью рефакторинг кода.

Помните все это, когда вам не хочется писать тесты. :)

Я хотел бы расширить ответ HLGEM , особенно этот раздел:

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

Я обнаружил, что код, который я пишу с целью написания тестов , значительно лучше кода, чем код, который я пишу без намерения писать тесты; спрашиваю себя, как я буду проверять эту функцию? заставляет лучший дизайн каждой функции. (Меньшая зависимость от глобальных или полуглобальных данных; IO отделен от вычислений; функции выполняют только одно; последовательная обработка ошибок; и т. Д.)

Попытка поставить тесты на старом коде, который не был написан с мыслью о тестировании, может быть не очень приятной.

Я использовал несколько методов:

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

б) Делайте сложные проекты с тестами (вы ездите). Это покажет, как мало ошибок существует в этом проекте. У меня был один сложный проект взаимодействия с сервером, который начал работать безупречно. Это никогда не подвело QA, и все интеграционные тесты прошли на 100% гладко. Эта система стала известна как высокостабильная, и общее руководство было доволен ею. Что вы делаете в этих ситуациях, так это то, как модульное тестирование позволило это сделать.

в) Потяните по одному человеку за раз. Тот, кто слушает тебя. Возьмите ошибки и покажите, как тесты выявляют глубокие и сложные проблемы. Это помогает. Это никогда не легко. Но как только у вас появится поклонник, он только поможет. Это эффект домино.

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