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

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

• Показывает, что дизайн становится проще
• Показывает, что предотвращает дефекты
• Сделать это эгоистичным, говоря, что только плохие программисты
• В эти выходные 2 члена команды должны были прийти на работу, потому что его код имел NULL ссылку, и он не тестировал его.

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

Вы знаете больше мотивов?

Это одна из самых сложных задач . Заставить своих людей это понять .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Показывает, что дизайн становится проще.

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

Показывая это, предотвращает дефекты.

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

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

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

@ Justin Standard : В начале нового проекта соедините младшего специалиста с собой или другим старшим программистом.

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

@ Justin Standard : прочтите презентацию Кейт Роудс " Модульное тестирование 101" .

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

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

@ Доминик Куни : Потратьте немного времени и поделитесь методами тестирования.

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

@ Доминик Куни : Ответьте на вопросы, примеры и книги.

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

@ Адам Хейл : Сюрприз обзор.

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

@ Rytmis : элементы считаются выполненными, только если для них есть тестовые примеры.

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

@ jmorris : Избавиться / пожертвовать .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изменить: [ Джастин Стандарт ]

Не унижайте себя, то, что вы говорите, в значительной степени правильное.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание: вам действительно нужен аддон thunderbird coloured-diffs, если вы планируете это сделать.

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

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

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

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

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

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

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

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

Удачи.

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

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

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

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

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

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

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

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

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

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

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

@ jsmorris

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

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

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

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

В исходном репозитории: используйте хуки перед каждым коммитом (например, pre-commit для 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 лет назад, занимаясь тестированием, и это стало моей карьерой, и я не променял бы это ни на что. Надежный отдел контроля качества, который должным образом сформирован и наделен полномочиями и полномочиями по улучшению программного обеспечения, столь же ценен, как и разработчики, изначально пишущие программное обеспечение.

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

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

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

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

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

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

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