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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИМО вам следует:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я бы сказал:

«Здесь мы используем TDD, что и вы будете делать, но сначала я хочу, чтобы вы освоились в среде .NET. Затем в через пару недель мы сядем и напишем вместе пару юнит-тестов ".

Думаю, это дает ему время переварить.