Должен ли я начинать с тестирования модулей при обучении нового разработчика?

Ответ 1

Не имея абсолютно никакого опыта в .NET, я бы сказал, обертывая голову вокруг TDD одновременно с обучением .NET.

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

Вы действительно хотите избежать путаницы - TDD - это хороший способ развития, но это не путь, а TDD! =.NET. На самом деле, он полностью ортогонален - пытается одновременно преподавать новую методологию и новую платформу? Я не вижу, как это хорошая идея.

Ответ 2

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

Забава, вы быстро переживаете, экономит время и деньги.

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

Как вы думаете, лучший подход было бы для того, чтобы скорость?

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

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

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

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

ИМО вы должны:

• Не торопите его (вместо этого пусть он научится делать это хорошо, прежде чем вы ожидаете, что он сделает это быстро)

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

Тем не менее, Я не думаю, что unit test всегда необходимо. Но в ситуации, когда это новый (неопытный) программист, и где вы, очевидно, уже решили, что 100% unit test охват был правильным для этого проекта, мне трудно понять, почему вы думаете об изменении своей разработки (если, возможно, эти функции, которые он был назначен, имеют некоторые требования к расписанию/качеству, которые отличаются от других функций).

Ответ 7

Похоже, что новый разработчик уже проходит через огонь.

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

Ответ 8

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

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

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

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

Вероятно, это будет не быстрый процесс, но, надеюсь, это даст ему хорошее заземление при тестировании TDD/unit

Ответ 9

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

Даже намекая, что "только разработчики uber ninja" должны выполнять модульное тестирование, это неправильное сообщение для отправки, особенно если вы оцениваете 100% -ную статистику покрытия.

Тестирование модулей учит одному API-интерфейсу тестируемого кода назад и вперед, не изучая разработчика, делая опасные непроверенные изменения производственного кода.

Что касается проблемы сложности - сложный код - это сложный код. Разработка ковбоя без модульных тестов не упрощает.

Ответ 10

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

Ответ 11

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

Ответ 12

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

Ответ 13

Я бы сказал:

"Мы используем TDD здесь, и вы тоже будете делать это, но сначала я хочу, чтобы вы получили удобство в среде .NET. Затем через пару недель мы сесть и скомпоновать пару модульных тестов вместе".

Я думаю, что это дает ему время для переваривания.