Самая важная вещь, которую следует передать при обучении TDD [закрыто]

Question

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

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

Что, по вашему мнению, нам следует сделать своим приоритетом в обучении?Какой аспект преподавания TDD является тот самое важное.Если вам нужно сделать две вещи, ничего страшного, я не буду удерживать вас за ОДНУ часть :)

Answer 1

Речь идет о дизайне.Его НЕТ о тестах.

Answer 2

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

Красный — Зеленый — Рефакторинг -> просто сделай это.

Answer 3

Тот факт, что ваши тесты пройдены, не означает, что код правильный.

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

Answer 4

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

Не пишите код в голове перед написанием теста.

Когда я впервые начал заниматься TDD, я «знал», каким должен быть дизайн.Я «знал», какой код хочу написать.Поэтому я написал тест, который позволил бы мне написать этот фрагмент кода.

Когда я это делал, я на самом деле не занимался TDD — поскольку сначала я писал код (даже если код был только у меня в голове :-)

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

Answer 5

Я предлагаю: «Будь терпеливым». Вначале это кажется странным.Для меня прошло, наверное, три проекта, прежде чем я начал чувствовать себя естественно.

Answer 6

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

Answer 7

На мой взгляд, TDD — это ритм (красный, зеленый, рефакторинг).Снижение ритма поможет вам преодолеть «горб» «не понять».И если вы не сможете снизить ритм, вы, скорее всего, не сможете долго придерживаться TDD.Суть ритма – маленькие шаги, о которых уже говорилось.Пишите как можно меньше кода и безжалостно проводите рефакторинг.

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

Answer 8

Подчеркните, что TDD — это сдвиг парадигмы для разработчика.с.Если вы формируете новую команду, помните, что потребуется до шести месяцев, чтобы команда стала полностью эффективной в качестве практиков TDD.Если у вас есть зрелая agile-команда, эффективно практикующая TDD, объединение в пары позволит новому разработчику приступить к делу после пары итераций.Более того, используя пары из одной команды для заполнения новой линии, вы можете ускорить работу новой линии на TDD гораздо быстрее, чем первую линию.

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

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

Answer 9

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

Answer 10

Продолжайте маленькими шажками.

Убедитесь, что ваши тесты охватывают очень небольшую область и, как говорит PhlipCPP:'Выполните МИНИМАЛЬНОЕ РЕДАКТИРОВАНИЕ, необходимое для прохождения теста.'

Несмотря на это, в TDD есть много чего, поэтому вам все равно придется убедиться, что вы ничего не упускаете.

Answer 11

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

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

Answer 12

Особое внимание уделите различным видам тестов.И тестирование «черного ящика», и тестирование «белого ящика» важны и преследуют разные цели.Тестирование «белого ящика» не предназначено для проверки правильности, поскольку оно не может протестировать всю систему.Это делается для того, чтобы сделать код еще более вонючим и, следовательно, обеспечить лучшее направление рефакторинга.Тестирование «черного ящика» предназначено для проверки правильности.Каждая функция должна быть протестирована методом «черного ящика».

Также обратите внимание на различия в покрытии тестами.Из-за проблем с комбинаторикой и повторяемостью невозможно протестировать каждый путь кода в вашем приложении по принципу «черного ящика».Мое правило состоит в том, что функция не является завершенной, пока она не будет протестирована в «черном ящике».Вы должны помочь ученикам разобраться в своих собственных правилах.Однако тесты «белого ящика» не должны иметь зависимостей от внешних классов;поэтому каждая строка каждого класса должна быть проверена методом «белого ящика».