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

Ответ 1

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

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

Ответ 2

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

(Неловкое выражение из-за гендерного нейтралитета.)

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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

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

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

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

• Сопряженное программирование (Ping Pong Pattern) -

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

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

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

Часть II (Мотивируя людей писать тесты)

Это то, с чем у меня были проблемы в прошлом. Несмотря на то, что я сейчас стараюсь выполнять TDD так часто, как это уместно, мне потребовалось несколько месяцев, чтобы увидеть, что реальная польза для написания тестов.
Я считаю, что, пытаясь показать другим, преимущества TDD и Unit Testing довольно сложны. Только когда человек испытывает для себя этот момент "ах ха", когда тесты TDD/Unit подчеркивают тонкость в их коде, что они могли бы пропустить иначе, или помогли им исправить ошибку за короткий промежуток времени, что они см. преимущества. Добиться их до этого момента может быть довольно сложно.
Лично я попал туда по парному программированию в вышеупомянутом Ping Pong Pattern, работая с опытным TDDer и рассматривая код, который мы пишем, чтобы решить нетривиальную функциональность, превратиться в то, что можно назвать элегантным решением. Далее следуют эта часть работы, которая проходит через QA и в Live Environment без каких-либо ошибок, возникших против него.

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

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

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

Ответ 10

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

Ответ 11

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

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

С учетом этого вы не будете получать большую выгоду от "лакеев", которые пишут тесты, потому что

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

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

Ответ 12

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

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

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

Ответ 13

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