Как вы убеждаете других писать модульные тесты?

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

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

Что я хочу знать, какие аргументы вы бы использовали, чтобы убедить других разработчиков начать писать модульные тесты? Большинство разработчиков, которых я познакомил с этим, хорошо справляются с этим, видят преимущества и продолжают использовать его. Это всегда, кажется, хорошие разработчики, хотя они уже заинтересованы в улучшении качества своего кода и, следовательно, могут видеть, как это делает модульное тестирование.

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

Ответ 1

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

Я работаю консультантом, и поэтому мне часто приходится решать проблему внедрения TDD в организации. К счастью, когда компании нанимают меня, это часто из-за моего опыта в определенных областях, и поэтому у меня может быть небольшое преимущество, когда речь заходит о привлечении внимания людей. Или, может быть, просто для меня это немного легче, чем для аутсайдера, чтобы прийти к новой команде и сказать: "Привет! Я пробовал TDD по другим проектам, и я знаю, что это работает!" Или, может быть, это моя убедительность/упрямство?:) В любом случае, мне часто не очень сложно убеждать разработчиков начать писать тесты. То, что мне трудно найти, - научить их писать хорошие модульные тесты. И как вы указываете в своем вопросе; оставаться на праведном пути.

Но я нашел один метод, который, как я думаю, работает очень хорошо, когда речь идет о тестировании модульных модулей. Я рассказал об этом здесь, но суть в том, чтобы сесть и сделать пару-программирование. И выполняя парное программирование, я начинаю сначала писать unit test. Таким образом, я немного покажу им, как работает среда тестирования, как я структурирую тесты и часто использую насмешку. Модульные тесты должны быть простыми, поэтому все тесты должны быть достаточно понятны даже для младших разработчиков. Худшая часть для объяснения часто является насмешкой, но использование легко читаемых смехотворных фреймворков, таких как Moq, помогает. Затем, когда тест написан (и ничего не компилируется или не проходит), я передаю клавиатуру моему коллеге, чтобы он мог реализовать эту функциональность. Я просто говорю ему/ему; "Сделай это зеленым!" Затем переходим к следующему тесту; Я пишу тест, "скоро будущий тест-инфицированный-dev" рядом со мной записывает функциональность.

Теперь важно понять, что на данный момент разработчики (ы), которые вы преподаете, вероятно, еще не уверены, что это правильный способ кодирования. Точка, по которой большинство разработчиков, похоже, видят (зеленый) свет, когда тест терпит неудачу из-за некоторых изменений кода, которые они никогда не думали, нарушали бы любую функциональность. Когда тест, который охватывает эту функциональность, взрывается, когда у вас есть верный TDD'er в вашей команде. Или, по крайней мере, мой опыт, но, как всегда; ваш пробег будет варьироваться:)

Ответ 2

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

Ответ 3

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

Тогда вы можете начать культуру, где "untested" является признаком плохого кодирования, "failed" является признаком незавершенного производства, а "пройденный" является признаком готового кода.

Это лучше всего работает, если вы также выполняете "тест-первый". Затем "untested" становится "вы забыли шаг 1".

Конечно, вам не нужно 100% -ное покрытие. Но из одной области охват 1%, а другой - 30%, у вас есть показатель, для которого область, скорее всего, терпит неудачу в производстве.

Ответ 4

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

Получение QA и управление бай-ином, чтобы ваш процесс требовал модульного тестирования.

Будьте готовы помочь другим, чтобы начать работу с модульным тестированием: предоставить помощь, предоставить структуру, чтобы они могли легко начать, запустить вводную презентацию.

Ответ 5

Вам просто нужно привыкнуть к мантре ", если она не проверена, работа не выполнена!"

Изменить: Чтобы добавить еще немного мяса в мои смешные комментарии выше, как кто-то может знать, действительно ли они завершены, если они не протестировали свою работу?

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

Индивидуальное разделение между усилиями для кодирования и тем, что для тестирования, кажется, хорошее число.

НТН

веселит,

Rob

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

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

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

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

Ответ 9

Вероятно, ответ reefnet_alex поможет вам: Тестирование модулей стоит усилий?

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

Ответ 10

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

например. ничто не может быть проверено до тех пор, пока не будет написано и просмотрено unit test.

Ответ 11

Вы упомянули, что ваш менеджер находится на борту с модульными тестами. Если это так, то почему он (она) не применяет его? Это не ваша работа, чтобы заставить всех остальных следовать или учить их, и на самом деле другие разработчики часто будут возмущаться вами, если вы попытаетесь нажать на них. Чтобы ваши разработчики могли писать модульные тесты, менеджер должен подчеркнуть его сильно. В конечном итоге это может означать образование на unit test исполнении, которое вы, возможно, окажетесь педагогом, и это здорово, но управление им - это все.

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

Ответ 12

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

Медленный и устойчивый - он не изменится за одну ночь.

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

Ответ 13

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

Это приводит к быстрому исправлению ошибок.