Старшие Разработчики и Модульные тесты - Необходимый? Им разрешают использовать лакеев? [закрытый]

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

(Неловкая формулировка из-за гендерного нейтралитета.)

Человек, пишущий тест = определение, как система должна работать = "босс"

Люди, реализующие тесты, являются так называемыми "лакеями"

Походит на случай старой собаки, которой не нравятся новые приемы. И как говорится, трудно заставить их изменяться... TFD (тестируют первую разработку) очень забавен, после того как Вы начинаете делать его, возможно, имеете внутренний 1-дневный семинар на TDD или TFD вовлечение целой команды.

Если старшие разработчики освобождены от поблочного тестирования

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

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

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

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

Первая часть (Старшие разработчики и поблочное тестирование)

Когда я думаю о TDD или Тесте Управляемый Дизайн, Модульные тесты служат цели вытеснить эволюционный дизайн системы, надо надеяться, гарантируя непрерывное совершенствование.
Запись теста формирует код или выделяет проблемы с решением, которое было уже принято, надо надеяться, приведя к процессу рефакторинга для увеличения качества дизайна.

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

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

1. Приемные Тестовые/Вплотную Тесты Тестов/Клиента. Назовите их, что Вы будете, но я имею в виду тесты, которые запускаются в точке ввода данных, (веб-сервис, веб-страница, вход экрана приложения), и пересекают всю стопку системы, (к базе данных, призовите к другому сервису, назад вокруг на входной экран результатов и т.д.). Это могло быть записано кем-то, кто не реализует детали отдельных единиц, которые будут осуществлены тестами.

2. Парное программирование (шаблон пинг-понга) -

   Записи новый тест и видит, что перестал работать.
   B реализует код, должен был пройти тест.
   B пишет следующий тест.
   Реализации это.

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

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

Вторая часть (Мотивирующий людей к тестам записи)

Это - что-то, с чем у меня были проблемы в прошлом. Даже при том, что я теперь пытаюсь выполнить TDD, поскольку часто является соответствующим, мне потребовались несколько месяцев, чтобы видеть, что была реальная выгода для записи тестов.
Я полагаю, что, пытаясь показать другим преимущества TDD и Поблочного тестирования являются довольно трудными. Это только, когда человек испытывает для себя, это 'ах ха' момент, когда TDD/модульные тесты выделил тонкость в их коде, который они, возможно, иначе пропустили или помогли им исправить ошибку за короткое количество времени, что они видят преимущества. Получение их к той точке может быть довольно трудным.
Лично я добрался там программированием пары в вышеупомянутом Шаблоне Пинг-понга, работой с опытным TDDer и наблюдением кода, который мы писали для решения нетривиальной части функциональности, развиваются в то, что можно было бы назвать изящным решением. Сопровождаемый той обрабатываемой деталью, делающей его через QA и в Продуктивную среду без любых дефектов, повышен против него.

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

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

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

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

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

Если старший разработчик не делает их собственного тестирования, то они не старший разработчик.

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

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

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

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

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

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

1. У них не будет всестороннего понимания всех тонких угловых случаев
2. Они не будут заботиться о коде, потому что им ничего не инвестировали в него
3. Они будут чувствовать, что их рассматривают как идиоты.

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

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