Как убедить товарищей по команде использовать TDD [закрыто]

Я единственный человек в моей команде, который использует TDD. Как мне заставить их использовать это?

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

Решат ли использование github, fork и pull request эту проблему, так что им нужно пройти тест до того, как pull будет принят?

Я не менеджер проекта, и я не могу убедить ее использовать это.

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

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

... когда я вытащу, чей-то код сломает мои тесты, и я тот, кто должен их исправить.

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

Это может звучать как тупик, но на самом деле это не так. Ваша конечная цель (убедить в TDD) все еще имеет смысл, не бросайте ее. Просто переориентируйте свои усилия на устранение обнаруженного препятствия.

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

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

Стоит отметить, что навыки разработки тестов, которые вы развиваете на «предварительном» этапе, скорее всего, понадобятся снова, если (когда :) вы наконец убедите своих товарищей по команде использовать TDD. Подумай об этом...

... Что произойдет, если разработка, основанная на тестировании, будет представлена ​​вашим неопытным коллегам?

Первое, на что стоит обратить внимание, это то, что парни начнут писать дерьмовые тесты и (ужас!) Даже ломать хорошие тесты во время обучения. Чтобы помочь им найти способ сделать это правильно, вам нужно достаточно глубокое понимание хорошего дизайна теста.

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

Когда я хотел поощрить использование Test Driven Development, я запустил Cyber-Dojo . В этом упражнении акцент делается не на самом коде, а на процессе написания кода .

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

Затем мы обсудили некоторые из основных принципов TDD, попросили всех сменить партнеров и повторить одно и то же ката. Мы повторили одно и то же ката, чтобы снять акцент с генерации кода и вместо этого сосредоточить внимание людей на процессе именования тестовых случаев и цикла Red / Green.

Затем мы повторили ката снова, но примерно каждые 10 минут один человек в каждой группе переходил в другую группу, имитируя довольно изменчивую командную среду, которую мы часто находимся в эти дни.

В последней итерации оба партнера каждые 10 минут менялись на разные группы. Это помогло продемонстрировать, что в случае TDD даже передача полномочий от одной команды совершенно другой не обязательно должна быть слишком болезненной, поскольку каждый проект должен иметь только один красный / зеленый цикл от работы.

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

Люди обычно говорили, что день был веселым и информативным, и сейчас мы ищем другие способы использования Cyber-Dojo на моем рабочем месте.

Cyber-Dojo , написанный Джоном Джаггером , невероятно хорошо подходит для такого рода упражнений. Это является веб-интегрированной средой для выполнения осознанной практики в TDD и изучение динамики команды. Он имеет множество ката, специально отобранных, чтобы помочь людям сконцентрироваться на процессе TDD, а не на проблеме. Он также поддерживает ряд языков, от Python и Ruby до Java и C ++.

Лучше всего, после выполнения ката, вы можете вернуться и посмотреть на красно-зеленую прогрессию (или, возможно, не * 8 ') каждой из участвующих групп. Его светофоры - отличный способ визуализировать, как работает процесс TDD.

Если вам нужен собственный сервер CyberDojo, весь проект можно найти на github, и оттуда даже связана виртуальная машина устройства под ключ Linux , что означает, что при условии, что у вас уже установлен проигрыватель VMware или VirtualBox , вы можете начать работу в несколько минут загрузки устройства!

Если они сопротивляются TDD, это нормально. У многих людей (включая меня) сначала возникают проблемы с написанием юнит-тестов.

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

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

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

Очень сложно убедить людей изменить свои привычки, но вот несколько вещей, которые вы можете попробовать:

• Поговорите с другими разработчиками и объясните им, почему вы считаете TDD хорошей идеей.
• Убедите их (или, по крайней мере, некоторых из них) попробовать это в течение ограниченного времени
• Постарайтесь установить некоторые минимальные требования для работы в команде. Им не обязательно выполнять TDD, но они, безусловно, не должны проверять код, который не проходит модульные тесты. Это отдельная проблема, чем убеждение их использовать TDD, и ее гораздо важнее решать.
• Попробуйте убедить руководство провести испытательный срок для TDD. Вы должны быть готовы предоставить некоторые доказательства того, почему это хорошая практика и как она сэкономит компании время и деньги в будущем.

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

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

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

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

Как говорилось во многих других «как мне убедить X использовать метод / технологию Y», мой ответ всегда один и тот же: на примере.

Используйте его и получите лучшие (измеримые) результаты. Затем убедитесь, что другие заметили.

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

Много полезных советов. А теперь еще немного ...

Вы должны завоевать сердца и умы (БУМ) один луддитов в то время. Забудьте об этом. Множество объектных уроков в течение неопределенного (извините за это) периода времени. В конце концов вы попадете в критическую массу, убедите «правильных» людей.

Ваш постоянный и постоянный энтузиазм и стремление к TDD очень важны в кампании WHAM.

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

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

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

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

Предупреждение: TDD не является лекарством и не может преодолеть плохой дизайн и кодирование ОО (но он определенно может это разоблачить). Не позволяйте луддитам обвинять усилия по тестированию кода в их некомпетентности.

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

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

• тесты сэкономят время при разработке, потому что вместо ручного тестирования (локальная попытка воспроизвести ошибку, игра с консолью rails ...) вы будете запускать тесты автоматически

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

• и что ты будешь делать с дополнительным временем? создавать вещи с морем и зарабатывать на них деньги :)

Что касается программистов, попробуйте следующий аргумент (он работал для меня, очень давно): «В любом случае вы тестируете код, с или без TDD. Только вы делаете это вручную, а не автоматизируете его. Умные разработчики автоматизируют как можно больше вещей. "

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

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

Могу поспорить, что вы не используете RAII и не хотите изучать и понимать это для вашего текущего проекта. То же, что и ваш коллега, который не хочет учиться и понимать TDD.