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

92

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

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

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

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

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

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

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

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

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

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

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

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

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

lurkerbelow
источник
Были ли другие 172 модульных теста, проведенных вами в предыдущие годы, или кто-то еще проводит модульные тесты, которые вы упрощаете?
JB Кинг
16
Эти другие 172 модульных теста были сделаны разработчиком, который покинул компанию. грустный :(
lurkerbelow
6
Пожалуйста, продолжайте говорить номера. Сколько ошибок было обнаружено за последний год, сколько из них было обнаружено и сколько было предотвращено юнит-тестами. Сколько времени занимает написание тестов (1521 в год на одного человека) против «Выполнения реальной работы» (с точки зрения ваших коллег, вероятно, думают). Воспринимают ли они UT как полезную или пустую трата времени. т.е. покажи мне деньги.
Mattnz
1
Из любопытства, есть ли у ваших коллег альтернативная стратегия отладки? TDD полезен для доказательства того, что что-то работает, как ожидалось, но не так много для неизвестных проблем. Им может быть удобно просто подключить отладчик.
Спенсер Рэтбун
3
Правильно использовать отладчик для тестирования, но это не гарантирует, что код будет работать через несколько дней / недель / месяцев, и это реальная проблема.
lurkerbelow

Ответы:

48

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

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

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

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

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

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

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

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

jimmy_keen
источник
Спасибо за ваш вклад. Я думаю, что я планирую встречу TDD с катами. Два разработчика на встречу, чтобы я мог помочь. Да, программное обеспечение "работает". Но многие ошибки «возвращаются». Если кто-то что-то исправляет в модуле A, возможно, подмодуль A1 больше не будет работать в некоторых случаях. Эти ошибки (в основном) не обнаружены во время QA. Это такая пустая трата времени. Написание юнит-тестов: (возможно) 1ч. Получение отчета об ошибке от клиента, анализ, планирование, исправление, проверка кода, сборка, доставка исправлений и т. Д. Около .. 6-8ч.
lurkerbelow
Картинка стоит 1000 слов и все. Показывать, что это экономит время, более убедительно, чем говорить, что это должно экономить время .
R0MANARMY
4
@lurkerbelow: аргумент возврата ошибок (или, если хотите, регрессии) является очень сильным. Подумайте об организации существующей проблемы или ошибки, на которую вы потратили слишком много времени в этих примерах, и покажите, как могли бы помочь написанные тесты.
км
10
По моему опыту, написание тестов не сокращает время разработки, по крайней мере, не заранее; это увеличивает это. Однако он производит более надежное, лучше спроектированное и более легкое в обслуживании программное обеспечение.
Роберт Харви
@RobertHarvey: вы правы, «разработка» - плохой выбор формулировок с моей стороны. Я не мог придумать ничего лучшего, описывающего процесс разработки, реализации, выпуска и обслуживания программного обеспечения. UT в долгосрочной перспективе, сократить / упростить этот процесс, и это то, что я имел в виду.
км
28

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

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

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

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

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

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

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

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

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

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

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

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

HLGEM
источник
9

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

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

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

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

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

ЭльЮсубов
источник
3
@lurkerbelow, хорошо, и теперь ваша следующая задача - следить за ошибками в sloc - следите за вашей системой отслеживания ошибок и изменениями кода, которые возникают. Если ошибок нет, то у вашего коллеги есть смысл. Если есть нагрузки, то у вас есть точка. В любом случае, у вас будут некоторые эмпирические доказательства.
gbjbaanb
3
Тот факт, что вы можете доказать, что ваши изменения не сломали что-то еще, на мой взгляд, является БОЛЬШОЙ силой. Немедленная реакция рабочего программного обеспечения также полезна. К сожалению, некоторые люди никогда не захотят попробовать стартап обучения. По иронии судьбы, этот ограниченный запуск для немедленного удовлетворения - это слишком много в нашей культуре немедленного удовлетворения ...
Дженнифер С.
7

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

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

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

gws2
источник
7

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

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

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

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

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

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

MathAttack
источник
Стоит отметить, что, не будучи уже в культуре, которая охватывает TDD, ваши коллеги не заставляют вас двигаться вперед, чтобы стать лучше в этом. Если они увидят слабость в вашем методе, они вызовут его и скажут «так что это никогда не сработает». Чтобы подавать пример, вы должны тратить свое время и силы на совершенствование своей методологии.
перфекционист
3

Спросите их.

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

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

Telastyn
источник
6
Теоретически это хорошая идея, но трудно ответить на вопрос. Итак, если вы знаете, что юнит-тесты хороши, почему вы их не используете? не звучит как мудак, например, я не знаю как, или у меня нет времени, или я умен, мой код должен работать . Такая ситуация обычно заставляет людей защищаться, и вы получите плохие результаты.
R0MANARMY
2
Я не хочу указывать на ошибки других народов. Может быть, мне следует поболтать, пока я один, например, выпить пива или десять. Время Давление на самом деле не точка. У нас отличный график с достаточным буферным временем. (150% + по оценкам)
lurkerbelow
2

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

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

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

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

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

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

bwalk2895
источник
1

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

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

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

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

оборота сарнольд
источник
1

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

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

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

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

user84575
источник
в) выглядит хорошо для моего случая
Накилон
0

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

Без шансов
источник
Спасибо за ваш вклад. Вы заявили, что написание модульных тестов заставляет разработчика задуматься над требованиями и т. Д. Иногда это действительно проблема. Функция А реализована и работает. QA сообщает dev, что тестовый пример x не работает, потому что он не думал о возможных побочных эффектах. Мы используем непрерывную интеграцию для обеспечения наших модульных тестов. Все тесты запускаются, если кто-то что-то проверяет. Поэтому мы бы уловили возможные побочные эффекты перед отправкой QA / клиентам.
lurkerbelow
1
Модульное тестирование отличается от интеграционного тестирования. Я считаю, что разработчик также несет ответственность за интеграционное тестирование, и роль QA заключается в том, чтобы убедиться, что все в порядке (в той степени, в которой они могут выполнить проверку). Конечно, могут быть проблемы с версиями, отсутствующими фрагментами, распространением кода на серверы и т. Д., Которые не могут быть обнаружены на раннем этапе, но они не имеют ничего общего с требованиями или модульным тестированием.
NoChance