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

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

22.08.2008 22:44:55
13 ОТВЕТОВ
РЕШЕНИЕ

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

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

20
22.08.2008 23:06:42
Я также учел бы комментарий @ gbjbaanb о том, что люди не должны проверять свой собственный код, поскольку они могут проверять только то, что, как они знают, сработает. Как и в дизайне, нельзя видеть ошибки как в своей работе, так и в чужой. Итак, Senior Devs должны тестировать, но не свою работу!
defmeta 7.12.2008 17:15:29
@defmeta «Не тестируйте свой собственный код» обычно относится к ручному функциональному тестированию. Модульные тесты должны быть написаны в первую очередь разработчиком, так как он предназначен для выражения спецификации. Разработчик, который пишет модульный тест, наверняка понимает спецификацию, достаточную для написания кода.
John Fricker 12.03.2009 03:58:03

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

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

2
22.08.2008 22:52:51

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

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

7
3.07.2012 14:54:58
точно причина НЕ для самопроверки. Вы знаете, где он ломается, и в итоге вы тестируете то, что работает. Кто-то еще будет тестировать таким образом, чтобы сломать его. Каждый должен проверить чужой код, никаких выходов.
gbjbaanb 18.11.2008 23:17:11

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

2
22.08.2008 23:05:35

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

Люди, которые проводят тесты - это так называемые "лакеи"

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

5
22.08.2008 23:09:46

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

4
22.08.2008 23:22:18

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

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

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

2
22.08.2008 23:22:27

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

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

5
22.08.2008 23:54:59

Часть I (Старшие разработчики и юнит-тестирование)

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

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

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

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

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

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

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

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

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

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

4
23.08.2008 12:29:36

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

2
27.08.2008 21:16:47

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

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

Имея это в виду, вы не получите большую пользу от «лакеев», пишущих тесты, потому что

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

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

1
28.08.2008 00:30:44

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

0
7.12.2008 15:18:55

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

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

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

1
7.12.2008 15:53:21