Как конвертировать магазин программного обеспечения в TDD?

Question

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

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

Answer 1

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

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

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

Answer 2

Хотя я не могу сказать вам, что будет работать, я могу сказать вам кое-что, что определенно не будет работать, и его следует избегать:

Я напишу код, ты пишешь тест

Сначала это всегда возникает. Люди предполагают, что, поскольку вы так любите тестирование, именно вы должны писать тесты. Это совсем не работает и упускает из виду весь смысл.

Вы написали тест, который не работает, поэтому вы должны исправить его.

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

Я просто начну, и все будут следовать.

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

Подать пример :

• использовать TDD для всего кода, который вы пишете
• покажите им преимущества, как только у вас появится такая возможность (регрессия, обнаруженная модульным тестом или инцидентом, воссозданным в вашей тестовой среде)
• доставить "чистый код, который работает"
• предложите свою помощь другим
• не будьте догматичны - TDD - это не серебряная пуля
• делает ваши юнит-тесты видимыми: они должны компилироваться вместе с кодом, который они тестируют

Answer 6

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

Что касается подталкивания TDD или какой-либо другой религии кода, не беспокойтесь.

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

Answer 7

Большая проблема с TDD, которая возникает «снизу вверх», состоит в том, что, когда наступает пуш (как это неизбежно происходит, когда приближается крайний срок), руководство собирается перевесить акцент на тестах: «Мы можем не могу проверить! Мы должны закончить проект! "

Конечно, это та самая ситуация (приближающийся крайний срок, значительное отставание, прогресс не в русле обещаний, приводящий к быстрому смещению приоритетов и задач), когда преимущества TDD действительно вступают в действие. / Итерация начинает разрушаться в том же старом и старом, и руководство оглядывается назад и говорит: «Мы попробовали TDD, но это не помогло».