Самая важная вещь, которую нужно передать при обучении TDD

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

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

Что бы вы сказали, мы должны сделать наш приоритет для обучения? Какой аспект обучения TDD является самым важным. Если вам нужно сделать две вещи, это нормально, я не буду удерживать вас до части SINGLE:)

Ответ 1

Это о дизайне. Это НЕ об испытаниях.

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

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

Ответ 9

Продолжайте выполнять детские упражнения.

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

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

Ответ 10

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

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

Ответ 11

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

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

Ответ 12

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

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