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

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

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

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

Знаете ли вы о других мотивах?

Ответов (24)

Решение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@ jsmorris

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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