Разработка через тестирование и программирование пары [закрываются]

Предложите им прочитать эти книги по TDD:

Майкл Фезер: Эффективная работа с устаревшим кодом
Классическая разработка Кента Бека через тестирование - на примере
Тест xUnit Джерарда Месароса Шаблоны - Рефакторинг тестового кода
Разработка через тестирование в Microsoft .NET

или эти веб-сайты по парному программированию:

Парное программирование (Википедия)
Кори Хейнс
Парное программирование с подсветкой

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

Что ж, в зависимости от менеджера вы можете указать на некоторые аргументы в литературе по XP о том, что эти методы взаимозависимы. Например, если у вас нет надежных модульных тестов, не проводите безжалостный рефакторинг.

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

Все равно сделай это. Если менеджер поймает вас в паре, произнесите волшебные слова «Проверка кода»
. Предположение: очевидно, что пара должна быть достаточно дисциплинированной / сосредоточенной и создать рабочий код в конце сеанса

Хотя одна практика не требует другого, есть «хитрый» способ ввести и то, и другое понемногу за раз.

Начните с цели реализации TDD с использованием одного из доступные фреймворки xUnit. Найдите совместимого сотрудника и спросите, готовы ли они работать с вами около часа в день. «Шон, я пробую этот новый инструмент, не могли бы вы помочь мне убедиться, что я все делаю правильно?» работает действительно хорошо.

Через пару дней с Шоном, повторите со Сьюзен ...

Парное программирование эффективно при изучении новой практики, особенно TDD

Таким образом, вы можете использовать и то, и другое с компромиссом. Делайте это постепенно, постепенно. Сначала займитесь парным программированием. Это самый простой из двух. Все практики после парного программирования станут намного проще для изучения и будут приняты командой быстрее и с большей последовательностью. Парное программирование - одна из первых, если не первая инженерная практика, которую следует принять. Убедитесь, что это сделано эффективно. Ниже приводится описание того, как выполнять парное программирование.

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

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

• Повышенное качество - Сопряжение способствует проверке кода. Многие ошибки обнаруживаются по мере их набора. Парное программирование означает непрерывный обзор кода, выполняемый двумя людьми, которые привержены качеству кода и постоянно работают вместе, чтобы выявлять и исправлять ошибки. Исследование, проведенное Университетом штата Юта, показало, что конечное количество дефектов, обнаруженных в коде, уменьшилось в среднем на 15% для кода, написанного парами.
• Меньше времени, затрачиваемого на «застревание» - программирование сложно. Часто разработчики изо всех сил пытаются найти решение и тратят больше времени, чем им следовало бы «застрять». Наличие партнера, с которым можно провести мозговой штурм и согласиться обратиться за помощью в случае необходимости, сокращает количество непродуктивного времени, затрачиваемого на поиски решения.
• Меньше времени, затрачиваемого на отвлекающие факторы - разработчик с меньшей вероятностью будет тратить время на личные телефонные звонки, просмотр веб-страниц или электронную почту в отпуске, когда он или она работает с партнером.
• К проблеме применяются две точки зрения - - Разный уровень опыта, разные стили решения проблем, разные вспомогательные навыки - все это увеличивает шансы на более быстрое решение проблемы. Исследование, проведенное Университетом Юты, также выявило лучший общий дизайн и меньшую длину кода для программного обеспечения, написанного парами.
• Меньше страха перед неизвестным - при объединении с другим разработчиком легче решить проблему или попытаться ее решить. справиться с новыми технологиями, чем при работе в одиночку. Со временем они также получат лучшее понимание всего приложения. В конце концов, проект заканчивается тем, что несколько человек понимают каждую часть системы в результате спаривания.
• Меньше возможностей для расширения - Часто разработчики охотно добавляют функциональные возможности, не указанные в требованиях. При работе в паре второй разработчик с большей вероятностью будет удерживать своего партнера на работе.
• Улучшенная командная динамика - благодаря парному подходу люди учатся работать вместе. Они чаще говорят и лучше передают информацию. В результате улучшается командная динамика. Фактически, мы обнаружили, что лучший опыт построения команды - это совместная работа над созданием программного обеспечения, которое нравится вашим клиентам. Всем нравится быть частью успешной команды.
• Устранение разрозненности знаний - знание предметной области, знания кода или практик быстро распространяются между командой и разработчиками в паре друг с другом на основе ротации.

Как только команда освоится с парой, переходите к TDD. Далее следует описание:

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

Разработка через тестирование требует, чтобы перед каждым аспектом самого кода был написан автоматизированный модульный тест, определяющий требования кода. Эти тесты содержат утверждения, которые являются либо истинными, либо ложными. Выполнение тестов дает быстрое подтверждение правильности поведения по мере развития кода и его рефакторинга. Среды тестирования, основанные на концепции xUnit, предоставляют механизм для создания и запуска наборов автоматизированных тестовых случаев. e

Разработка через тестирование требует, чтобы перед каждым аспектом самого кода был написан автоматизированный модульный тест, определяющий требования кода. Эти тесты содержат утверждения, которые являются либо истинными, либо ложными. Выполнение тестов дает быстрое подтверждение правильности поведения по мере развития кода и его рефакторинга. Среды тестирования, основанные на концепции xUnit, предоставляют механизм для создания и запуска наборов автоматизированных тестовых случаев. e

Разработка через тестирование требует, чтобы перед каждым аспектом самого кода был написан автоматизированный модульный тест, определяющий требования кода. Эти тесты содержат утверждения, которые являются либо истинными, либо ложными. Выполнение тестов дает быстрое подтверждение правильности поведения по мере развития кода и его рефакторинга. Среды тестирования, основанные на концепции xUnit, предоставляют механизм для создания и запуска наборов автоматизированных тестовых случаев. Цикл разработки через тестирование: Следующая последовательность основана на книге «Разработка через тестирование на примере», которую многие считают каноническим исходным текстом по концепции в ее современной форме.

1. Напишите тест. При разработке через тестирование каждая новая карта истории начинается с написания теста. Этот тест не пройден, потому что он написан до того, как функция была реализована. Чтобы написать тест, разработчик должен четко понимать спецификацию и требования функции. Это может быть выполнено с помощью Story Cards с критериями приемки, чтобы указать, когда требования были выполнены. Это также может означать инвариант или модификацию существующего теста. Это отличительная черта разработки через тестирование по сравнению с написанием модульных тестов после написания кода: это заставляет разработчика сосредоточиться на требованиях перед написанием кода - тонкое, но важное отличие.
2. Запустите все тесты и посмотрите, не сработает ли новый. Это подтверждает, что тестовая программа работает правильно и что новый тест не проходит по ошибке, не требуя нового кода. Новый тест также должен завершиться неудачно по ожидаемой причине. На этом этапе тестируется сам тест, но он дает отрицательный результат: он исключает возможность того, что новый тест всегда будет проходить успешно и, следовательно, бесполезен.
3. Напишите код. Следующим шагом будет написание кода, который заставит тест пройти. Новый код, написанный на этом этапе, не будет идеальным и может, например, неэлегантно пройти тест. Это приемлемо, потому что дальнейшие шаги улучшат и отточат его. Это подтверждает, что тестовая программа работает правильно и что новый тест не проходит по ошибке, не требуя нового кода. Новый тест также должен завершиться неудачно по ожидаемой причине. На этом этапе тестируется сам тест, но он дает отрицательный результат: он исключает возможность того, что новый тест всегда будет проходить успешно и, следовательно, бесполезен.
4. Напишите код. Следующим шагом будет написание кода, который заставит тест пройти. Новый код, написанный на этом этапе, не будет идеальным и может, например, неэлегантно пройти тест. Это приемлемо, потому что дальнейшие шаги улучшат и отточат его. Это подтверждает, что тестовая программа работает правильно и что новый тест не проходит по ошибке, не требуя нового кода. Новый тест также должен завершиться неудачно по ожидаемой причине. На этом этапе тестируется сам тест, но он дает отрицательный результат: он исключает возможность того, что новый тест всегда будет проходить успешно и, следовательно, бесполезен.
5. Напишите код. Следующим шагом будет написание кода, который заставит тест пройти. Новый код, написанный на этом этапе, не будет идеальным и может, например, неэлегантно пройти тест. Это приемлемо, потому что дальнейшие шаги улучшат и отточат его. это исключает возможность того, что новый тест всегда будет успешным и, следовательно, бесполезным.
6. Напишите код. Следующим шагом будет написание кода, который заставит тест пройти. Новый код, написанный на этом этапе, не будет идеальным и может, например, неэлегантно пройти тест. Это приемлемо, потому что дальнейшие шаги улучшат и отточат его. это исключает возможность того, что новый тест всегда будет успешным и, следовательно, бесполезным.
7. Напишите код. Следующим шагом будет написание кода, который заставит тест пройти. Новый код, написанный на этом этапе, не будет идеальным и может, например, неэлегантно пройти тест. Это приемлемо, потому что дальнейшие шаги улучшат и отточат его. Важно, чтобы написанный код был рассчитан только на прохождение теста; никакие дальнейшие (и, следовательно, непроверенные) функциональные возможности не должны прогнозироваться и «разрешаться» на любом этапе.
8. Запустите автоматизированные тесты и убедитесь, что они успешны. Если все тестовые примеры пройдены, программист может быть уверен, что код соответствует всем протестированным требованиям. Это хорошая точка для начала последнего шага цикла.
9. Рефакторинг кода. Теперь код можно очистить по мере необходимости. Повторно запустив тестовые примеры, разработчик может быть уверен, что рефакторинг не повредит какой-либо существующей функциональности. Концепция удаления дублирования - важный аспект любого дизайна программного обеспечения. Однако в этом случае это также применимо к удалению любого дублирования между тестовым кодом и производственным кодом - например, магические числа или строки, которые повторялись в обоих, чтобы пройти тест на шаге 3.

Повторить

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

Стиль разработки Существуют различные аспекты использования разработки, основанной на тестировании, например, принципы «Держи это просто, глупо» (KISS) и «Тебе это не понадобится» (YAGNI). Сосредоточившись на написании только кода, необходимого для прохождения тестов, проекты могут быть чище и яснее, чем это часто достигается другими методами. Разработка через тестирование требует, чтобы программист сначала провалил тестовые примеры. Идея состоит в том, чтобы убедиться, что тест действительно работает и может выявить ошибку. Как только это будет показано, начнется нормальный цикл. Это было придумано «мантрой разработки через тестирование», известной как красный / зеленый / рефакторинг, где красный означает неудачу, а зеленый - пройдено. При разработке через тестирование постоянно повторяются шаги по добавлению неудачных тестовых случаев, их прохождению и рефакторингу. Получение ожидаемых результатов тестирования на каждом этапе укрепляет мысленную модель кода программиста, повышает уверенность и производительность

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

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

Лично я обнаружил, что парное программирование лучше всего работает с одним опытным и одним неопытным.

Т.е. я бы стремился к разнице в навыках / опыте программистов, а не пытался сопоставить их с одинаковыми навыками.

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

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

Модульные тесты необходимы имо ... в конце концов, некоторые сотрудники не будут там через 2 года.