Как заставить младших программистов писать тесты?

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

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

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

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

Я предполагаю, что он тоже довольно новый сотрудник (

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

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

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

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

Боюсь, что это намного сложнее, чем должно быть. Вы услышите множество отговорок вроде «Я очень спешу, я перепишу / реорганизую это позже, а затем добавлю тесты» - и, конечно, этого никогда не произойдет, потому что, как ни странно, они это так же занят на следующей неделе.

Это одна из задач самые сложные вещи. Привести ваших людей в возьми.

Иногда один из лучших способов помочь программистам младшего уровня «понять это» и изучить правильные техники у старших - это немного попарно.

Попробуйте следующее: в предстоящем проекте объедините младшего специалиста с собой или с другим старшим программистом. Они должны работать вместе, по очереди «управляя автомобилем» (вводя текст на клавиатуре) и «обучая» (глядя через плечо водителя и указывая на предложения, ошибки и т. д. По ходу движения). Это может показаться пустой тратой ресурсов, но вы обнаружите:

1. Что эти ребята вместе могут создавать код намного быстрее и качественнее.
2. Если ваш младший парень узнает достаточно, чтобы «понять это» со старшим, направив его по правильному пути (например, «Хорошо, а теперь, прежде чем мы продолжим, давайте напишем при тестировании этой функции»). Это будет стоить ваших ресурсов. совершить это.

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

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

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

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

Я бы не стал особо подчеркивать фактор стыда / вины. Стоит отметить, что тестирование - это широко распространенная, хорошая практика и что написание и поддержка хороших тестов - это профессиональная вежливость, поэтому вашим товарищам по команде не нужно проводить выходные на работе, но я бы не стал вдаваться в подробности.

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

Вот что бы я сделал:

• Первый раз ... "мы собираемся сделать этот проект совместно. Я собираюсь написать тесты, а вы собираетесь писать код. Обратите внимание на то, как я пишу тесты, потому что вот как мы это делаем. здесь, и это то, чего я от вас жду ".

• После этого ... «Готово? Отлично! Сначала давайте посмотрим на тесты, которые управляют вашей разработкой. О, никаких тестов? Дайте мне знать, когда это будет сделано, и мы перенесем рассмотрение вашего кода. Если вы» Если вам нужна помощь в составлении тестов, дайте мне знать, и я вам помогу ».

Проверяйте код перед каждой фиксацией (даже если это 1 минута «Я изменил это имя переменной»), и в рамках проверки кода просмотрите все модульные тесты.

Не подписывайтесь на фиксации, пока тесты не будут готовы.

(Также - если его работа не была протестирована - почему она вообще была в производственной сборке? Если она не протестирована, не впускайте ее, тогда вам не придется работать по выходным)

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

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

Примечание: вам В самом деле нужен аддон с цветными различиями thunderbird, если вы планируете это сделать.

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

Вы можете помочь людям привыкнуть к этому, периодически говоря что-то вроде: «Эй, Боб, ты видел, что я совершил сегодня утром? Я нашел этот изящный трюк, где ты можешь делать что угодно, читать коммит и смотреть. как это устроено!"

NB: У нас есть 2 «старших» разработчика и 3 младших разработчика. Это может не масштабироваться, или вам может потребоваться немного скорректировать процесс с большим количеством разработчиков.

Представьте, что я псевдопрограммист по имени ... Марко. Представьте, что я закончил школу не так давно, и мне никогда не приходилось писать тесты. Представьте, что я работаю в компании, которая на самом деле этого не требует и не требует. ОК? хороший! А теперь представьте, что компания переходит на использование тестов, и они пытаются приучить меня к этому. Я буду несколько язвительно реагировать на упомянутые выше пункты, как будто я не проводил никаких исследований по этому поводу.

Начнем с создателя:

Showing that the design becomes simpler.

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

Showing it prevents defects.

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

Making it an ego thing saying only bad programmers don't.

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

@Justin Standard: On start of new propect pair the junior guy up with yourself or another senior programmer.

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

@Justin Standard: Read Unit Testing 101 presentation by Kate Rhodes.

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

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

@Dominic Cooney: Spend some time and share testing techniques.

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

@Dominic Cooney: Answer questions, examples and books.

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

@Adam Hayle: Surprise Review.

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

@Rytmis: Items are only considered done when they have test cases.

Ох, интересно. Я вижу, что мне действительно нужно это сделать сейчас, иначе я ничего не доделываю. Это имеет смысл.

@jmorris: Get Rid / Sacrifice.

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

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

Рассуждения, подготовка, обучение, наблюдение, поддержка.

Его наставник обязан научить его / ее. Насколько хорошо вы его / ее учите КАК тестировать? Вы занимаетесь парным программированием с ним? Младший, скорее всего, не знает, КАК настроить хороший тест для xyz.

Будучи первокурсником, он знает много понятий. Некоторая техника. Некоторый опыт. Но в конце концов, все Юниоры ПОТЕНЦИАЛЬНО. Почти в каждой функции, над которой они работают, будет что-то новое, чего они никогда раньше не делали. Конечно, Младший мог сделать простой паттерн состояния для проекта в классе, открывая и закрывая «двери», но никогда не применял эти паттерны в реальном мире.

Он / она будет настолько хорош, насколько хорошо вы преподаете. Если бы они были в состоянии «получить это», как вы думаете, они бы заняли позицию юниоров в первую очередь?

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

@ jsmorris

Однажды старший разработчик и «архитектор» отругал меня и тестировщика (это была моя первая работа после колледжа) по электронной почте за то, что я не задержался допоздна и закончил такую ​​«легкую» задачу накануне вечером. Мы занимались этим весь день и объявили, что все закончится в 19:00. Я бился с 11:00 до обеда в тот день и приставал к каждому члену нашей команды с просьбой о помощи как минимум дважды.

Я ответил и отправил копию команде: "Я разочаровался в вас в течение месяца. Мне никогда не помогает команда. Я буду в кафе через улицу, если я вам понадоблюсь. Извините, я не смог отладить параметр 12, 800-строчный метод, от которого зависит практически все ".

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

"Так значит, ты уходишь?"

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

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

Не у всех одинаковый уровень таланта и / или мотивации. Команды разработчиков, даже гибкие, состоят из людей из «A-Team» и людей из «B-Team». Члены A-Team - это те, кто проектирует решение, пишет весь нетривиальный производственный код и общается с владельцами бизнеса - вся работа, требующая нестандартного мышления. B-Team занимается такими вещами, как управление конфигурацией, написание сценариев, исправление неполноценных ошибок и выполнение работ по техническому обслуживанию - все работы, требующие строгих процедур, которые имеют небольшие последствия в случае сбоя.

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

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

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

Конечно, толком ничего не знаю. Но я надеюсь, что эти слова были полезны.

Edit: [Justin Standard]

Don't put yourself down, what you have to say is pretty much right on.

On your point about code reviews: what you will find is that not only will the junior dev learn in the process, but so will the reviewers. Everyone in a code review learns if you make it a collaborative process.

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

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

Мне посчастливилось оказаться под наблюдением доброго и терпеливого старшего программиста очень. К счастью для меня, он решил сесть со мной и потратить 1-2 недели на изучение моего очень взломанного кода вместе. Он объяснил, в чем я ошибся, детали буквы c и указателей (мальчик, это меня сбило с толку!). Нам удалось написать довольно приличный класс / модуль примерно за неделю. Все, что я могу сказать, это то, что если бы старший разработчик не потратил время на то, чтобы помочь мне на правильном пути, я, вероятно, не продержался бы очень долго.

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

Возьмите домой очки

1. Большинство университетов очень плохо готовят студентов к реальной жизни.
2. Парное программирование мне очень помогло. Нельзя сказать, что это поможет всем, но у меня это сработало.

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

Что касается себя, я начал настаивать на том, чтобы каждая обнаруженная и исправляемая ошибка выражалась в виде теста:

1. "Хммм, это не так ..."
2. Найдите возможную проблему
3. Напишите тест, покажите, что код не работает
4. Решить проблему
5. Покажите, что новый код проходит
6. Зациклить, если исходная проблема сохраняется

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

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

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

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

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

1. Сделайте покрытие кода частью обзоров.
2. Сделайте «написать тест, который выявляет ошибку» предварительным условием для ее исправления.
3. Прежде чем код можно будет зарегистрировать, требуется определенный уровень покрытия.
4. Найдите хорошую книгу по разработке, основанной на тестировании, и используйте ее, чтобы показать, как метод «сначала тестирование» может ускорить разработку.

В исходном репозитории: используйте перехватчики перед каждой фиксацией (например, перехватчик предварительной фиксации для SVN)

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

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

Только автоматические проверки могут хорошо масштабироваться в проекте. Вы не можете все проверить вручную.

Разработчик должен иметь возможность проверить, покрывают ли его тестовые примеры 100% кода. Таким образом, если он не фиксирует 100% протестированный код, это его собственная ошибка, а не ошибка типа «ой, извините, я забыл».

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

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

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

Много психологии и полезных техник «наставничества», но, честно говоря, все сводится к «напиши тесты, если хочешь завтра иметь работу».

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

Следовательно, если кто-то откажется выполнять свою работу, объясните им, что завтра они могут остаться дома, и вы наймете того, кто БУДЕТ делать эту работу.

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

Удачи.

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

Если ваша организация достаточно велика, чтобы иметь более 6 разработчиков, я настоятельно рекомендую создать отдел обеспечения качества (даже если для начала нужен всего один человек). В идеале у вас должно быть соотношение 1 тестировщик на 3-5 разработчиков. Дело в том, что программисты ... они программисты, а не тестировщики. Мне еще предстоит провести собеседование с программистом, который формально обучен правильным методам обеспечения качества.

Большинство организаций допускают фатальный недостаток, назначая роли тестирования новому сотруднику, человеку с НАИМЕНЬШИМ уровнем воздействия на ваш код - в идеале старшие разработчики должны быть переведены на роль QA, поскольку у них есть опыт работы с кодом. и (надеюсь) развили шестое чувство запаха кода и точек сбоя, которые могут возникнуть.

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

В вашем случае, если вы можете позволить себе перенаправленную работу, сделайте этого нового парня первым членом вашей команды QA. Попросите его прочитать «Тестирование программного обеспечения в реальном мире: улучшение процесса», потому что ему, очевидно, потребуется некоторое обучение в его новой роли. Если ему это не нравится, он уйдет, и ваша проблема все равно будет решена.

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

Боковое примечание: в конце концов, вы захотите, чтобы команда QA отчитывалась перед директором QA или, по крайней мере, не перед менеджером разработчика программного обеспечения, потому что наличие отчета группы QA перед менеджером, основной целью которого является выполнение продукта, является конфликтом интерес.

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

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

Если PP не для вас, то TDD - ваш лучший выбор, но только если понимать его буквально. Разработка через тестирование означает, что вы пишете тесты СНАЧАЛА, запускаете тесты, чтобы доказать, что они действительно не работают, а затем пишете простейший код, чтобы заставить его работать. Компромисс теперь в том, что у вас (должен) быть набор из тысяч тестов, который также является кодом, и с такой же вероятностью, как и в производственном коде, будут содержаться ошибки. Честно говоря, я не большой поклонник TDD, в основном по этой причине, но он работает для многих разработчиков, которые предпочли бы писать тестовые сценарии, чем документы тестовых примеров - какое-то тестирование лучше, чем ничего. Соедините TDD с PP для большей вероятности покрытия тестами и меньшего количества ошибок в скрипте.

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

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

Он уже этим занимается. Действительно. Он просто не записывает. Не убежден? Посмотрите, как он проходит стандартный цикл разработки:

• Напишите кусок кода
• Скомпилируйте это
• Беги посмотреть, что он делает
• Напишите следующий фрагмент кода

Шаг № 3 - это проверка. Он уже делает тестирование, просто делает это вручную. Задайте ему вопрос: «Как вы узнаете завтра, что код с сегодняшнего дня все еще работает?» Он ответит: «Как мало кода!»

Спросите: "Как насчет следующей недели?"

Если он не получит ответа, спросите: «Как бы вы хотели, чтобы ваша программа сообщала вам, когда изменение нарушает что-то, что работало вчера?»

Вот что такое автоматическое модульное тестирование.

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

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

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