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

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

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

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

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

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

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

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

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

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

jsmorris

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

я ответил и cc'd команда с: "Я разочаровывался в Вас в течение месяца теперь. Я никогда не получаю справку от команды. Я буду в кафе через улицу, если Вам нужен я. Я сожалею, что не мог отладить 12 параметров, 800 методов строки, от которых примерно все зависит".

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

"Так Ваш выход тогда?"

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

Это - обязанность его Наставника Учить его. Как хорошо Вы учащий ему, КАК протестировать. Вы - программирование пары с ним? Более, чем вероятный Junior не знает, КАК настроить хороший тест для xyz.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следовательно, если кто-то собирается отказаться делать их задание, объясняют им, что они могут остаться дома, завтра, и Вы наймете кого-то, кто сделает задание.

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

Удача.

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

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

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

Примечание: Вы действительно хотите тандерберд цветное-diffs дополнение , если Вы планируете выполнение этого.

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

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

нбар: у Нас есть 2 'старших' devs и 3 младших. Это не может масштабироваться, или Вы, возможно, должны были бы скорректировать процесс немного с большим количеством разработчиков.

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

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

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

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

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

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

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

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

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

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

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

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

Счастливо, 2 года по линии, я надеялся бы, что некоторые мои коллеги могли бы даже считать меня средним программистом.

Забирают домой точки

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

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

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

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

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

• Запись часть кода
• Компиляция это
• Выполнение для наблюдения, что это делает
• Запись следующая часть кода

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

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

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

Это - то, о чем автоматическое поблочное тестирование - все.

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

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

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