Старшие разработчики и модульные тесты-требуется? Можно ли им использовать лакеев?

Я бы сказал, что с точки зрения пуриста TDD (т. е. тот, кто считает, что модульные тесты должны быть написаны до реализации), старшие разработчики должны писать больше модульных тестов, чем лакеи, а не меньше .

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

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

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

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

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

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

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

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

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

Часть I (старшие разработчики и модульное тестирование)

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

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

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

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

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

   А пишет новый тест и видит, что он неудачи.
   B реализует необходимый код чтобы пройти испытание.
   Б пишет следующее тест.
   Ее осуществление.
   
   
   

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

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

Часть II (мотивация людей к написанию тестов)

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

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

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

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

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

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

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

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

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

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

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

Имея это в виду, вы не получите большой пользы от написания тестов 'lackeys', потому что

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

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

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

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

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

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