Так.. Я должен обучаться, команда на Поблочном тестировании - могла использовать C&C на плане урока
Таким образом - управление надеется делать нажатие, чтобы двинуть выполнение поблочного тестирования во всем продвижении приложений - и в конечном счете войти в полный TDD / Непрерывный режим сборки Интеграции/Автоматизировать (я надеюсь). В этой точке однако мы просто обеспокоены получением всех разрабатывающих приложения продвижение поблочного тестирования использования. Я хотел бы только запуститься с основ.
Я не буду лгать - я не безусловно никакой эксперт каким-либо образом в поблочном тестировании, но у меня действительно есть достаточно хорошее понимание, чтобы запустить инициативу с основ и позволить нам выращивать togeather как команде. Я действительно любил бы получать некоторые комментарии и критику от всего Вы эксперты по моему плану нападения на эту вещь. Это - команда приблизительно 10 разработчиков в небольшом магазине, который делает для прекрасной возможности продвинуться с методологиями гибкой разработки и лучшими практиками.
Прежде всего - команда состоит из главным образом середины разработчиков уровня с несколькими младшими devs и одного старшего, всех с минимальным ни к какому воздействию поблочному тестированию. Обучение будет выходящей два раза в месяц встречей в течение приблизительно 30-60 минут каждый раз (вероятно, завершают выполнение один час длиной, которое я предположил бы и возможно имел бы их чаще). Мы продолжим эти встречи, пока не будет иметь смысл останавливать их, чтобы позволить другим догонять свою собственную 'домашнюю работу' и опыт - но нажатие будет всегда идти.
Так или иначе - вот мой план урока, который я придумал. Ну, первые два, по крайней мере. Любой совет от Ваших экспертов там по фактическому содержанию или структуре уроков, и т.д., был бы большим. Comments & Critisism значительно ценится.Большое спасибо.
Я приношу извинения, если это 'слишком много', чтобы отправить в здесь или прочитать. Я думаю, что это было бы большим потоком для ТАК пользователей, надеющихся входить в поблочное тестирование во-первых также. Возможно, Вы могли просто пропустить к разделу 'планов уроков' - еще раз спасибо все.
ПРИМЕЧАНИЯ УТЕСА - я понимаю, что это сообщение невероятно длинно и ужасно, таким образом, вот примечания утеса - Урок 1 будет 'привет мировыми модульными тестами' - Урок 2 будет открывать решение моего нового приложения и показывать, как применить каждого 'привет мировой' пример в реальной жизни... Большое спасибо все для обратной связи Вы дали мне до сих пор.. просто wantd для выделения того, что урок 2 будет иметь реальные производственные модульные тесты в нем, так как многие предложили, чтобы я сделал это, когда это был мой план с начала =)
План урока поблочного тестирования
Обзор
Почему модульный тест? Походит на набор дополнительной работы - итак, почему делают это?
• Станьте ведущим устройством своей собственной судьбы. Большинство наших пользователей не делает истинного UATs и к сожалению склонно делать свое тестирование однажды в производстве. С модульными тестами мы значительно уменьшаем риск, связанный с этим, особенно когда мы создаем достаточно данных тестирования и принимаем во внимание столько высокоуровневых исходных данных, сколько мы возможно можем. Не будучи 'серебряной пулей', которая предотвращает все ошибки – это - Ваш первый оборонительный рубеж – огромная линия фронта, сопоставимая с тем из Гигантов чемпионата SB.
• Поблочное тестирование осуществляет хороший дизайн и методы архитектуры. Это - ‘жестокий психопат, который поддерживает Ваш код и знает, где Вы живете’ так сказать. Вы просто не можете написать код низкого качества, который хорошо протестирован на единицу
• Сколько раз Вы не осуществили рефакторинг вонючий код, потому что Вы также боялись повреждения чего-то? Автоматизированное тестирование удаляет этот страх, делает рефакторинг намного легче, в свою очередь делающий код более читаемый и легче поддержать.
• Нижняя строка – обслуживание становится намного легче и более дешевым. Время, проведенное при записи модульных тестов, могло бы быть дорогостоящим теперь – но время, это сохраняет Вас в будущем, как доказывали, снова и снова было намного более ценным. Это - причина № 1 автоматизировать тестирование Вашего кода. Это вселяет нам веру, которая позволяет нам брать более амбициозные изменения в системах, что мы должны были иначе уменьшить требования к или возможно даже не взять вообще.
Обзор терминологии
• Поблочное тестирование - тестирование самого низкого уровня, единицы работы. НАПРИМЕР, – тестируют все возможные пути выполнения кода, что единственная функция может течь через.
• Интеграционное тестирование - тестирование, как сотрудничают Ваши единицы. Например, – выполняет 'задание' (или ряд вызовов функции), который делает набор работы, с известными исходными данными - и затем запрашивает базу данных в конце и утверждает, что значения - то, что Вы ожидаете от тех исходных данных известных (вместо того, чтобы иметь необходимость к глазному яблоку сетку на веб-странице где-нибудь, например, сделать функциональное испытание).
• Фальшивки – фальшивка является типом объекта, цель которого состоит в том, чтобы использовать для Вашего тестирования. Это позволяет Вам слишком легко не тестовый код, который Вы не хотите тестировать. Вместо того, чтобы иметь необходимость назвать код, который Вы не хотите – как вызов базы данных – Вы используете поддельный объект 'фальсифицировать' тот вызов DB и возможно считать данные из файла XML/Excel или платформы насмешки. o Насмешка – тип фальшивки, к которой Вы делаете операторы контроля против. o Тупик – тип фальшивки, к которой Вы используете в качестве кода заполнителя, таким образом, можно пропустить вызов базы данных, но не делают, утверждает против
Уроки
Урок один – Привет Миры
• Привет Мировой модульный тест - я создам ‘привет мировое’ консольное приложение, которое является протестированной единицей. Создаст это приложение на лету во время встречи, показ инструментов в Visual Studio 2008 (тестовый проект, панель инструментов инструментов тестирования, и т.д.), что мы собираемся использовать по пути при объяснении, что они делают. Это будет иметь только единственный модульный тест. (Хорошо, возможно, я не создам его 'на лету' =), иметь для размышления о нем больше). Также объяснят Утверждать класс и его цель и общий поток модульного теста.
• Привет Мир, немного более сложный. Теперь наша функция имеет различные пути / логические ответвления, код может течь через. У нас будет ~3 модульных теста на эту функцию. Это будет предзаписанным решением, которое я делаю перед встречей.
• Привет Мир, внедрение зависимости. (Не использующий платформ DI). Предзаписанное решение, которое создает от предыдущего, на этот раз с помощью внедрения зависимости. Объяснит, что DI, и покажите образец того, как он работает.
• Привет Мир, Фиктивные объекты. Предзаписанное решение, которое создает от предыдущего, на этот раз с помощью нашего недавно добавленного кода DI для введения фиктивного объекта в наш класс, чтобы показать, как насмешка работает. Будет использовать NMock2.0, поскольку это - единственное, у меня есть воздействие. Очень простой пример, чтобы просто отобразить использование фиктивных объектов. (Возможно, поместите этого в отдельный урок?).
• Привет Мир, (неавтоматизированный) Интеграционный тест. Создавая от предыдущего решения, мы создаем интеграционный тест так шоу, как протестировать 2 функции вместе, или весь класс вместе (возможно, помещает этого в отдельный урок?)
Урок два – теперь мы знаем основы – как применить это в реальной жизни?
• Общий обзор лучших практик o Правило № 1-Единственный Принципал Ответственности. Единственный Принципал Ответственности. Единственный Принципал Ответственности. Остроумно заявление, что это - единственная самая важная вещь иметь в виду при написании кода. Класс должен иметь только одну цель; функция должна сделать только одну вещь. Ключевое слово здесь является тестом 'единицы' – и SRP сохранит Ваши классы и функции инкапсулировавшими в единицы. o Внедрение зависимости Ваш почти лучший друг. DI позволяет Вам 'включать' поведение в классы, которые Вы имеете во время выполнения. Среди прочего это - то, как мы используем платформы насмешки для создания наших больших классов более легко тестируемыми.
o Всегда думают, ‘как я протестирую это’, поскольку Вы - написание кода. Если кажется ‘слишком трудным протестировать’, вероятно, что Ваш код является слишком сложным. Осуществите рефакторинг, пока это в более логические единицы классов/функций - не посещает тот один урок, который делает 5 вещей и превращает его в 5 классов, тот, который называет другие 4. Теперь Ваш код будет намного легче протестировать – и также легче считать и осуществить рефакторинг также.
o Тестовое поведение, не реализация. В ореховой скорлупе это означает, что мы можем по большей части протестировать только Государственные функции на наших классах. Мы не заботимся о тестировании частных (реализация), потому что общедоступные (поведение) - то, что использует наш код вызова. Например... Я - разработчик программного обеспечения-миллионер и перехожу к представительству Aston Martin для покупки меня совершенно новый DB9. Парень продаж говорит мне, что это может сделать 0-60 через 3 секунды. Как Вы протестировали бы это? Вы изъяли бы механизм и выполнили бы диагностические тесты и т.д.? Нет... Вы взяли бы его на бульвар и сделали бы 160 миль в час =). Это тестирует поведение по сравнению с реализацией.
• Рассматривание реальной жизни протестированное на единицу заявление. Здесь мы пробежимся через каждое вышеупомянутое ‘привет мировые’ примеры – но реальные версии, с помощью моего нового проекта в качестве примера. Я открою простой модульный тест, более сложный, тот, который использует DI и тот, который использует Насмешки (вероятно, связанный с DI один). Этот проект является довольно маленьким и простым, таким образом, это - действительно идеальное соответствие. Это будет также включать тестирование DAL и как установить тестовую базу данных для запущения этих тестов против.
10 ответов
Я помогал разработать и провести тренинг по разработке через тестирование в своей компании для разработчиков Java. В итоге мы сделали это тренировкой на целый день и разделили ее так же, как и здесь.
- Зачем проводится тестирование?
- Простой пример.
- Более сложный пример.
Одна вещь, которую я должен Однако стресс - это людям нужно учиться, выполняя .
Для моего обучения мы создали лабораторную среду, в которой каждый студент мог бы начать с одного и того же снимка кода, а также самостоятельно разрабатывать и запускать тесты, с инструкторами, ходящими по комнате для тренировок, помогая людям, которые были сбиты с толку или не понимали.
Для «Простого примера» у нас была версия кода «кулинарного шоу», которая была на проекторе и прошла этап процесса TDD шаг за шагом. Разработчикам придется пройти через процесс написания теста, затем создать реализацию, достаточную для прохождения теста, а затем повторить. На каждом этапе подготовленное решение для текущего этапа показывалось на проекторе после того, как у студентов было время попробовать его самостоятельно.
Для «Сложного примера» мы создали набор требований, а затем разрешили учащимся придумывать собственные решения, используя для этого TDD. У нас даже было упражнение, в котором требования неожиданность, неожиданность внезапно изменились на этапе выполнения упражнения.
Мне нравится ваша идея делать это в течение более длительного периода времени с регулярными проверками. Одним из недостатков нашего обучения было отсутствие контроля. Я уверен, что разработчики извлекли пользу из обучения, но многие, я думаю, не вернули практику к своей обычной работе.
I like the commitment and thoroughness you're expressing here, but my feeling is your adoption plan is going to take longer this way than if you started straight in, paired up and wrote some actual production tests. You'll need infrastructure anyway -- why not bootstrap your actual production code with a CI server and a TDD framework? (A lot of times this is a bigger pain point than learning "asserts." Get this part out of the way sooner rather than later). Then sit down and solve an actual problem with a fellow coder. Pick a simple bug or small feature and try to identify what the failing tests would look like and try to write them.
I like Hello Worlds for a brown bag lunch or something. But I can't think of any reason not to just jump right in and solve some problems.
Привлечь людей, заинтересованных в модульном тестировании чужого / образца кода, будет не так эффективно, как если бы люди «начали с тестового примера» над новым кодом, который они должны написать. Изучите основы начала работы с тестовым примером и триангуляции для получения допустимого результата (при этом подчеркивая, что неудачный тест - это прогресс).
Тем не менее, мой личный опыт показывает, что подобные вещи лучше выполнять в среде парного программирования. Это дополнительная работа для вас, но сочетание индивидуальной работы, некоторого владения и рабочего примера, на который они могут ссылаться в конце, значительно облегчит внедрение.
Запуск инструмента покрытия в какой-то момент позже может в подходящей обстановке обеспечивают веселый, соревновательный и приятный способ отметить прогресс. Делать это каким-либо образом частью компенсации / бонусов - очень плохая идея. Если все сделано правильно, люди примут его, потому что он работает.
Я думаю, что будет сложнее начать с тестирования типа «тест после». Основное различие по сравнению с test-first заключается в том, что test-after не помогает вам при написании кода, который легко протестировать. Если вы сначала не сделали TDD, будет очень сложно написать код , для которого будет легко писать тесты .
Я рекомендую начать с TDD / BDD, и после того, как вы освоите это, продолжайте изучать, как выполнить тестирование после устаревшего кода (также PDF ). ИМО, выполнить «тест-после» намного сложнее, чем «сначала тестировать».
Чтобы изучить TDD, я рекомендую завершить этот учебник . Это должно помочь вам понять, какие тесты писать.
Это стиль учебной аудитории подход будет работать хорошо? Это вопрос, который приходит мне в голову, поскольку то, что может здесь произойти, представляет собой такое большое разделение между знанием и применением идей, что, хотя они могут знать это, они не совсем понимают, как это использовать.
Просто чтобы дать другой подход, можно было бы сразу перейти к текущим проектам и попытаться применить некоторые из них, что может занять некоторое время, чтобы просочиться через всех, поскольку идея заключалась бы в том, что вы тренируете одного, а затем в паре тренируйте другую пару и так далее, чтобы попытаться подвести всех к одной и той же точке. Таким образом, теоретический материал, который не имеет отношения к делу, удаляется раньше.
Другая идея заключалась бы в том, чтобы посмотреть, есть ли смысл попытаться сформировать команды в группе из 10 человек, например, 2 группы по 3 человека и группу из 4 или 5 пар, чтобы каждый человек мог представить, что он сделал. и насколько хорошо они это используют.
Я бы поддержал проверку границ, а также показал, почему может быть полезно тестирование с недопустимыми входными данными, чтобы увидеть, что это не приводит к тому, что система перевернется и умрет.
Наконец, может иметь смысл уделить время рассмотрению вопросов и других проблем 1: 1, которые возникают у людей, поскольку не все захотят задавать вопросы перед большой группой.
РЕДАКТИРОВАТЬ: предупреждение по Уроку 2, Это хорошая идея, но есть несколько опасностей, на которые следует обратить внимание. Во-первых, выполняя этот урок, будьте скромны, чтобы не показаться хвастуном, желающим раскритиковать всех остальных. Во-вторых, я Я предлагаю оставить некоторые тесты незавершенными при рассмотрении вещей, чтобы здесь был интерактивный аспект, который не позволял другим разработчикам просто отключиться или закатить глаза. В-третьих, один или два дополнительных урока, показывающие, что они сделали, или вы повторяете то, что они сделали, могут быть более полезными, чтобы показать, что это в некотором роде командная работа.
Я пытался внедрить TDD в небольшой команде (7-9 программистов). Лекции не удались. Люди настроены скептически, TDD звучит как змеиное масло. Кроме того, всегда есть пресловутый Вилли.
В конце концов, вместо TDD, люди в команде время от времени проводят DDT (тесты, управляемые разработкой): пишут модульные тесты после кода, чтобы подтвердить, что он делает то, что они хотели. Выглядит как полный провал, пока вы не поймете, что даже эта форма контроля качества, управляемая разработчиками, намного лучше, чем то, что было у вас раньше, потому что, даже если она на самом деле не улучшает код для будущих повторений, она сокращает развернутые ошибки.
Однако было одно ключевое отличие по сравнению с вашей настройкой: толчок исходил не от руководства, они были достаточно хороши, чтобы позволить программистам решать самим.
Лекции провалились, но я не положил все яйца в одну корзину. Я написал кучу тестов для многих более мелких, более сфокусированных функций и классов, используемых в проекте. Эти маленькие жукеры, которых вам иногда нужно немного согнуть, чтобы точно поместиться на следующей площадке, надеясь, что вы не сломали ни одну из существующих (вы просмотрели код, изменение показалось безопасным). Он запускал тесты после каждого второго svn up (не только мной) и последующих ответов на электронные письма о виновных в фиксации: «Вы сломали его, пожалуйста, исправьте как можно скорее!» это окончательно убедило их в хотя бы частичной полезности модульных тестов.
Независимо от того, какие примеры вы приводите для лекций, они скажут вам, что это сработало только потому, что CUT был нереалистично (или необычно) изолирован от остальной части код. Oни' попрошу вас написать модульные тесты для запутанного, глючного класса Бога (желательно синглтона, всем нравятся глобальные переменные, не так ли?), потому что, насколько им известно, именно так выглядит реальный код , и они думают, что то же самое будет и с TDD.
К черту лекции. Попросите руководство купить всем по несколько книг на Рождество: по крайней мере, TDD By Example (Бек) и Refactoring (Фаулер). Судя по опыту, книги не обязательно будут иметь какое-либо влияние на большинство из них (больше чуши о том, что «этого недостаточно для реального мира»), но это обязательно зацепит кого-то, и, без обид, я бы поставил 1000 долларов, что Бек лучший евангелист из вас двоих. ;) Практикуйте TDD в коде, которым вы делитесь с ними. Если это действительно сработает, они последуют. Ссс-лоу-у-у-уу, но они будут.
С другой стороны, может быть, у вас не так много Вилли в вашей команде, может быть, ваши коллеги хотят, им просто нужен лидер, я действительно не знаю, вы не сказал.
Заповедь первая: не откладывайте медленное и / или частичное всасывание: каждый дюйм на счету! (Я здесь себе проповедую, я знаю ...)
Я думаю, что это хороший план для одного или двух сеансов. Но я настоятельно рекомендую сначала создать инфраструктуру тестирования и настроить разработчиков на ранний успех, вместо того, чтобы загонять разработчиков в мир модульного тестирования и кричать «готово, готово, ИДТИ!»
Предполагая, что вы разрабатываете в среде IDE инструмент генератора тестов одним щелчком мыши действительно поможет на первом этапе, создании теста. Вы захотите интегрировать средство запуска тестов на основе графического интерфейса в свою IDE, и вам действительно нужен автоматический запуск тестов, интегрированный с вашими сборками CI. Интеграция инструмента покрытия кода с инструментом запуска тестов поможет разработчикам расширить охват. Вам необходимо предоставить разработчикам полную структуру для написания тестов, включая документирование того, как организовать исходный код теста (стандарты именования тестов, настройки проекта, расположение папок и т. Д.). Инструменты, которые автоматизируют любой из ручных шагов, будут долгий путь. Предоставьте имитацию фреймворка, включая фиктивные объекты для любых собственных или сторонних библиотечных API, от которых вы зависите. Если вы собираетесь рекомендовать базу данных, полную поддельных данных (вместо набора поддельных объектов доступа к данным), создайте базу с несколькими ключевыми таблицами и заполните ее тестовыми данными, а также предоставьте все необходимое для ее сброса между запусками тестирования. Если не, приведите несколько собственных поддельных DAO в качестве примеров. У вас должен быть небольшой набор тестов уже в вашей системе управления версиями, тестирующий производственный код, чтобы показать его в качестве примеров. И вам нужно все это задокументировать, чтобы вы могли передать это на собрании №1. (Не забудьте протестировать документ!)
Одна из наших групп пару лет назад попробовала специальный подход , но его внедрение было плохим. Без определений или организации тестов отдельные разработчики как бы делали свое дело. Отсутствие стандарта именования затрудняло определение правильных тестов, запускаемых для каких модулей, и мало кто беспокоился. У нас не было интеграции с IDE ни для одного из них. Никто не хотел писать макеты, и мы не предоставили заранее макеты для используемого фреймворка. И действительно сложно добавить тесты в устаревший код, который не t написан с учетом внедрения зависимостей.
Сейчас я пытаюсь реорганизовать нашу инфраструктуру и подготовить ее к еще одному выстрелу в этой задаче. Только после того, как он встанет, я буду работать над тем, чтобы заставить разработчиков использовать его снова.
Однако у вас есть одна вещь, которой нам как бы не хватало в прошлый раз, - это сильная поддержка со стороны руководства. Наши предыдущие менеджеры отнеслись к этой идее в некотором роде равнодушно, потому что они не хотели откладывать кодирование, создавая все эти тесты. Теперь у нас новое руководство, и они сосредоточены на качестве кода - сейчас в моде автоматические модульные тесты, так что сейчас хорошее время для нас, чтобы попробовать еще раз.
s стоя, буду ли я работать над тем, чтобы заставить разработчиков использовать его снова.Однако у вас есть одна вещь, которой нам как бы не хватало в прошлый раз, - это сильная поддержка со стороны руководства. Наши предыдущие менеджеры отнеслись к этой идее в некоторой степени равнодушно, потому что они не хотели откладывать кодирование из-за необходимости писать все эти тесты. Теперь у нас новое руководство, и они сосредоточены на качестве кода - сейчас в моде автоматические модульные тесты, так что сейчас хорошее время для нас, чтобы попробовать еще раз.
s стоя, буду ли я работать над тем, чтобы заставить разработчиков использовать его снова.Однако у вас есть одна вещь, которой нам как бы не хватало в прошлый раз, - это сильная поддержка со стороны руководства. Наши предыдущие менеджеры отнеслись к этой идее в некоторой степени равнодушно, потому что они не хотели откладывать кодирование из-за необходимости писать все эти тесты. Теперь у нас новое руководство, и они сосредоточены на качестве кода - автоматизированные модульные тесты сейчас в моде, так что сейчас хорошее время для нас, чтобы попробовать еще раз.
Мне нравится. Один комментарий, который у меня есть, - вероятно, стоит добавить несколько рекомендаций / советов о том, как проводить тестирование многопоточного / асинхронного кода.
Кроме того, я бы сделал комментарий о пограничном тестировании , то есть об использовании модульных тестов для изложите свои предположения относительно любого стороннего API, который вы используете.
Just because I have been doing something where TDD (and unit tests in general) has been invaluable and because it might make a good demo, I'd suggest an example using Regex, especially if you aren't a Regex expert, it's quite easy to make mistakes.
It'd also make for a good 'show, not tell' demo. If you just:
step 1: Tell them just to write some code with a Regex to match a certain pattern.
step 2: expand the pattern to something else.
step 3: show how unit tests immediately let them be sure that a) it matches the new pattern and b) it hasn't broken any of the previous matches or let through results that shouldn't be.
In general C&C of your review, it's hard to get an idea of exactly what sequence events will go in. Also, semi-month seems far too infrequently if there's just a void inbetween with no push to apply their knowledge. The last thing you want is it to become some meeting they go to and forget about as soon as they are out of the room!
Do you have sufficient downtime in your current workload to address technical debt and get the team to actually pair up and start looking at adding unit tests to some existing functionality and refactoring where necessary to allow mocking?
I would say that will prove far more effective than lectures and potted workshops, YMMV.
Если менеджмент серьезно относится к этому, то они должны взять быка за рога и самим принимать меры, а не просто немного тренироваться. Начните просить их видеть тесты в обзорах кода. Как только это станет обычным делом и люди узнают, что они не пройдут проверку кода без теста, пусть откажутся внедрять новый код до тех пор, пока не будут написаны тесты. Это займет всего пару итераций, прежде чем люди узнают, что они не могут уйти от написания тестов, и тогда они сделают это достаточно надежно. Да, с первым отказом менеджера развернуть что-то, вероятно, будет поздно. Они должны принять это во внимание в своем собственном планировании. Им также нужно будет начать добавлять время на написание тестов к оценке своих задач. Никто не хочет этого делать, если думает, что будет виноват, так как написание тестов и кода занимает больше времени, чем просто написание кода. Публикуйте график того, как это будет реализовано (нужно дать им время, чтобы они научились это делать, прежде чем это понадобится для всех новых разработок), и по прошествии времени ничто не дойдет до продавливания без тестов.