Итак, мне нужно обучить команду Unit Unit - можно использовать C & C на плане уроков

Таким образом, руководство стремится сделать шаг, чтобы двигаться к выполнению модульного тестирования во всех приложениях, продвигающихся вперед, и, в конечном итоге, войти в полноценный режим TDD/Continuous Integration/Automated build (надеюсь). Однако на данный момент мы просто обеспокоены тем, что все разработчики приложений продвигаются вперед с помощью модульного тестирования. Я бы хотел начать с основ.

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

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

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

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

ЗАМЕТКИ CLIFF. Я понимаю, что этот пост невероятно длинный и уродливый, так что вот записки об утесе. Урок 1 будет "приветствовать мировые модульные тесты". Урок 2 откроет мое решение самое последнее приложение и демонстрируя, как применять каждый пример "привет мир" в реальной жизни... Большое спасибо всем за отзывы, которые вы мне дали до сих пор. Просто хочу подчеркнуть тот факт, что урок 2 будет иметь в нем тестируются реальные единицы производства, так как многие из них предлагают мне это, когда это был мой план с самого начала =)

План занятий по тестированию модулей

Обзор

Почему unit test? Похоже на кучу дополнительной работы - так зачем это делать?

• Станьте хозяином своей собственной судьбы. Большинство наших пользователей не делают настоящих UAT и, к сожалению, как правило, делают свое тестирование один раз в производстве. При модульных тестах мы значительно уменьшаем риск, связанный с этим, особенно когда мы создаем достаточное количество тестовых данных и учитываем как можно больше ресурсов верхнего уровня. Хотя это не "серебряная пуля, которая предотвращает все ошибки", это ваша первая линия обороны - огромная линия фронта, сопоставимая с победой гигантов чемпионата SB.

• Unit-Testing обеспечивает хорошие методы проектирования и архитектуры. Это "насильственный психопат", который поддерживает ваш код и знает, где вы живете, так сказать. Вы просто не можете написать плохой качественный код, который хорошо протестирован с помощью модуля

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

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

Обзор терминологии

• Единичное тестирование - тестирование самого низкого уровня, единицы измерения. НАПРИМЕР. - проверить все возможные пути кода, через которые может проходить одна функция.

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

• Подделки - подделка - это тип объекта, целью которого является использование для вашего тестирования. Это позволяет вам слишком легко не тестировать код, который вы не хотите тестировать. Вместо того, чтобы вызывать код, который вам не нужен - как вызов базы данных - вы используете поддельный объект для "подделать этот вызов БД и, возможно, читать данные из файла XML/Excel или насмешливую структуру. o Mock - тип подделки, к которому вы делаете утверждения. o Stub - тип подделки, который вы используете в качестве кода-заполнителя, поэтому вы можете пропустить вызов базы данных, но не делайте утверждений против

Уроки

Урок один - Hello Worlds

• Hello World unit test - Я создам "консольное приложение hello world", которое будет проверено модулем. Создаст это приложение на ходу во время собрания, показывая инструменты в Visual Studio 2008 (тестовый проект, панель инструментов инструментов тестирования и т.д.), Которые мы будем использовать по пути, объясняя, что они делают. Это будет только один единичный тест. (Хорошо, может быть, я не создам его "на лету" =), подумайте об этом больше). Также объяснит класс Assert и его назначение и общий поток единичного теста.

• Hello World, немного сложнее. Теперь наша функция имеет разные пути/логические ветки, через которые может протекать код. У нас будет ~ 3 модульных теста для этой функции. Это будет предварительно написанное решение, которое я делаю перед собранием.

• Hello World, инъекция зависимостей. (Не использовать какие-либо рамки DI). Предварительно написанное решение, которое строится на предыдущем, на этот раз с использованием инъекции зависимостей. Объяснит, что такое DI, и покажите образец того, как он работает.

• Hello World, Mock Objects. Предварительно написанное решение, которое основывается на предыдущем, на этот раз, используя наш недавно добавленный код DI, чтобы ввести в нас классный объект, чтобы показать, как насмехаются работы. Будет использовать NMock2.0, поскольку это единственный, с которым я подвергаюсь воздействию. Очень простой пример, чтобы просто отображать использование макетных объектов. (Возможно, поместите это в отдельный урок?).

• Hello World, (неавтоматизированный) тест интеграции. Создав предыдущее решение, мы создаем интеграционный тест, чтобы показать, как тестировать две функции вместе или весь класс вместе (возможно, поместите это в отдельный урок?)

Урок два - теперь мы знаем основы - как применить это в реальной жизни?

• Общий обзор передового опыта o Правило № 1- Одиночная ответственность. Одиночная ответственность. Одиночная ответственность. Честно говоря, это самое важное, что нужно помнить при написании кода. Класс должен иметь только одну цель; функция должна делать только одно. Ключевым словом здесь является "единичный тест", и SRP будет содержать ваши классы и функции, инкапсулированные в единицы. o Dependency Injection - ваш второй лучший друг. DI позволяет вам "подключать поведение к классам, которые у вас есть, во время выполнения. Среди прочего, это то, как мы используем насмешливые фреймворки, чтобы сделать наши более крупные классы более легко проверяемыми.

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

o Тестирование, а не реализация. В двух словах это означает, что мы можем в большинстве случаев проверять только публичные функции на наших классах. Мы не заботимся о тестировании частных (реализация), потому что публичные (поведение) - это то, что использует наш кодовый код. Например... Я разработчик программного обеспечения миллионера и отправляюсь в автосалон Aston Martin, чтобы купить себе новый DB9. Продавец говорит мне, что он может делать 0-60 за 3 секунды. Как бы вы это протестировали? Вы бы сняли двигатель и выполнили диагностические тесты и т.д.? Нет... Ты бы взял его на бульвар и сделал 160 миль в час =). Это тестирование поведения и реализации.

• Просмотр приложения с проверкой работоспособности в реальном времени. Здесь мы рассмотрим каждый из приведенных выше примеров "hello world", но реальных версий, используя мой последний проект в качестве примера. Я открою простой unit test, более сложный, который использует DI, и тот, который использует Mocks (вероятно, связан с DI одним). Этот проект довольно мал и прост, так что он действительно идеально подходит. Это также будет включать тестирование DAL и как настроить тестовую базу данных для запуска этих тестов.

Ответ 1

Я помог разработать и запустить тренинг Test Driven Development в моей компании для разработчиков Java. Мы закончили это как полный дневной тренинг, и мы разделили его так же, как вы здесь.

Почему тестирование?
Простой пример.
Более сложный пример.

Одна вещь, которую я должен подчеркнуть, - это человек, который должен учиться, делая.

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

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

В "Комплексном примере" мы создали набор требований, а затем позволили студентам придумать свои собственные решения, используя TDD. У нас даже было упражнение, в котором были удивлены требования, внезапно внезапно изменился путь через упражнение.

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

Я попытался представить TDD в небольшой команде (7-9 программистов). Лекции не удались. Люди скептически относятся, TDD звучит как змеиное масло. Кроме того, всегда есть пресловутый Вилли.

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

Было, однако, одно ключевое отличие по сравнению с вашей настройкой: толчок не исходил от руководства, они были достаточно хороши, чтобы программисты сами решали.

Лекции провалились, но я не поместил все яйца в одну корзину. Я написал множество тестов для многих более мелких, более сфокусированных функций и классов, используемых в проекте. Те маленькие жулики, которые вам иногда нужно немного сгибать, чтобы точно вписаться на следующий сайт, надеясь, что вы не сломаете ни одного из существующих (вы просмотрели код, изменение казалось безопасным). Он запускал тесты после каждого другого svn up (не только меня), а последующие ответы на сообщения о виновных совершениях "вы его нарушили, pls исправить как можно скорее". что, наконец, убедило их, по крайней мере, в частичной утилите модульных тестов.

Независимо от того, какие примеры вы придумали для лекций, они скажут вам, что это работает только потому, что CUT был нереалистично (или необычно) изолирован от остальной части кода. Они попросят вас написать модульные тесты для запутанного, глючного God Class (желательно Singleton, все любят глобальные переменные, нет?), Потому что, насколько им известно, что выглядит код реального мира, и они думают, что он будет выглядеть так же с TDD.

Винные лекции. Попросите руководство купить все несколько книг на Рождество: по крайней мере, TDD по примеру (Beck) и рефакторинг (Fowler). Говоря по опыту, книги не обязательно будут иметь какое-либо влияние на большинство из них (более того, это была не совсем реальная хватка), но она обязана придерживаться кого-то, и, d bet $1000, что Бек является лучшим евангелистом из вас двоих.;) Практикуйте TDD самостоятельно в коде, с которым вы делитесь. Если это действительно сработает, они последуют за ними. Sss-looowww-lyyyy, но они будут.

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

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

Ответ 5

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

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

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

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

Наконец, имеет смысл иметь время, посвященное обработке вопросов и другим проблемам 1:1, которые люди имеют, поскольку не все хотят задавать вопросы перед большой группой.

РЕДАКТИРОВАТЬ: Внимание к уроку 2, это хорошая идея, но есть несколько опасностей. Во-первых, будьте скромными в этом занятии, чтобы вы не встречались как хвастовство, желая хлопнуть всех остальных. Во-вторых, я предлагаю оставить некоторые тесты незавершенными при переходе на другие вещи, так что здесь есть интерактивный аспект, который не позволяет другим разработчикам просто настраивать или закатывать глаза. В-третьих, последующий урок или два других, показывающих, что они сделали или вы переходите на то, что они сделали, могут быть более полезными, чтобы показать, что это командная работа в некотором роде.

Ответ 6

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

Я рекомендую начинать с TDD/BDD, и после того, как вы это заметите, продолжайте учиться делать тест после устаревший код ( также PDF). ИМО, делая тест-после колодца, намного сложнее, чем тестирование.

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

Ответ 7

Я думаю, что это хороший план для сеанса или двух. Но я бы настоятельно рекомендовал сначала создать инфраструктуру тестирования и настроить разработчиков на ранний успех, вместо того, чтобы перетаскивать разработчиков в мир тестирования модулей и кричать "ready, set, GO!"

Предполагая, что вы работаете в среде IDE, инструмент генератора тестового генератора с одним щелчком мыши действительно поможет с первого шага, создания теста. Вы хотите интегрировать тестовый бегун на основе графического интерфейса с вашей IDE, и вам действительно нужен автоматический тестовый бегун, интегрированный с вашими сборками CI. Наличие инструмента покрытия кода, интегрированного с инструментом тестирования, поможет разработчикам увеличить охват. Вам необходимо предоставить разработчикам полную структуру для написания тестов, а также документацию по организации тестового исходного кода (тестовые стандарты именования, параметры проекта, местоположения папок и т.д.). Инструменты, которые автоматизируют любые шаги руководства, будут долгий путь. Предоставьте макетную фреймворк, включая макетные объекты для любых API-интерфейсов библиотеки или сторонних библиотек, от которых вы зависите. Если вы собираетесь рекомендовать базу данных, полную поддельных данных (вместо набора поддельных объектов доступа к данным), создайте ее с несколькими ключевыми таблицами и заполните ее тестовыми данными и предоставите все, что требуется для reset, между тестированием пробеги. Если нет, предоставьте несколько поддельных DAO, чтобы они послужили примерами. У вас должен быть небольшой набор тестов уже в вашем тестовом коде тестирования системы управления версиями, чтобы показать их в качестве примеров. И вам нужно, чтобы все это было документировано, чтобы вы могли передать его на встрече №1. (Не забудьте проверить документ!)

Одна из наших команд несколько раз пыталась применить ad hoc, но усыновление было неудовлетворительным. Без определений или организации тестов отдельные разработчики делали свое дело. Отсутствие стандарта именования затрудняло определение правильных тестов для запуска, для которых модули, и мало кто беспокоился. У нас не было интеграции IDE для любого из них. Никто не хотел писать насмешки, и мы не предусмотрели нас за рамки, которые мы используем. И действительно сложно добавить тесты к устаревшему коду, который не был написан с учетом зависимостей.

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

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

Ответ 8

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

Ответ 9

Мне это нравится. Один из комментариев, который у меня есть, это, вероятно, стоит отбросить некоторые рекомендации/советы о том, как идти о тестировании потокового/асинхронного кода.

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

Ответ 10

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

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

Шаг 1: Скажите им просто написать код с регулярным выражением, чтобы он соответствовал определенному шаблону.

Шаг 2: разверните шаблон на что-то еще.

Шаг 3: покажите, как модульные тесты немедленно позволяют им убедиться, что a) он соответствует новому шаблону, и b) он не нарушил ни одного из предыдущих совпадений или не дал результатов, которых не должно быть.

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

У вас есть достаточный простои в вашей текущей рабочей нагрузке для удовлетворения технического долга и заставить команду фактически объединиться и начать смотреть на добавление модульных тестов на некоторые существующие функции и рефакторинг, где это необходимо, чтобы позволить насмехаться?

Я бы сказал, что это будет намного эффективнее, чем лекции и семинары в горшках, YMMV.