Что такое Разработка через тестирование (Test Driven Development)

Зачем тестировать? Цель написания тестов — убедиться, что код, который вы пишете, работает должным образом, и вы ничего не сломали при добавлении новых функций или рефакторинге кода. Автоматизация является неотъемлемой частью разработки программного обеспечения, тогда почему мы должны продолжать проводить ручные тесты снова и снова, имея шанс пропустить некоторые важные сценарии тестирования? Вместо этого позвольте роботам делать скучные задания за вас.

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

Что такое Разработка через тестирование (Test Driven Development)

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

TDD — это процесс, который использует тесты для проектирования и разработки вашего приложения. Циклы разработки в нем называются Красный, Зеленый, Рефакторинг (Red, Green, Refactor).

Красный, Зеленый, Рефакторинг

Давайте рассмотрим на примере этот поток красный, зеленый и рефакторинг.

Например, представьте, что вы хотите создать функцию sort_array (), которая может сортировать массив в порядке возрастания.

Красный

Подумайте о том, что вы хотите сделать.

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

ВХОД: [34, 3, 12, 2]
ВЫХОД: [2, 3, 12, 34]

Когда вы запустите тест, вы увидите такую ошибку.

Зеленый

Подумайте, как пройти тесты.

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

После реализации функции sort_array () мы должны увидеть сообщение о прохождении теста, которое выглядит следующим образом.

Рефакторинг

Подумайте, как улучшить вашу существующую реализацию.

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

Снова Красный.

Ожидаемый результат не соответствует фактическому результату, который мы получаем…

Ожидаем: [3, 8, 21, 99]
Получаем: [2, 3, 12, 34]

Это потому, что мы возвращаем первый отсортированный массив! Не заботясь о других примерах (не реализован какой-либо алгоритм сортировки). Найдите минутку, чтобы подумать, как подойти к рефакторингу функции sort_array () и написать код для сортировки массива в порядке возрастания.

Теперь, если вы снова запустите rspec, вы увидите, что оба тестовых примера проходят.

По мере рефакторинга sort_array (), когда мы завершаим процесс рефакторинга и снова запустим наш набор тестов, мы должны получить следующий вывод:

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

3 закона Разработки через тестирование (Test Driven Development)

Вот они:

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

Трудно сказать, как они работают, просто прочитав их. Попробуйте сами, почувствуйте разницу.

Что еще почитать про Test Driven Development

• Подкаст Podlodka №11: Test Driven Development
• 40 советов, которые навсегда изменят ваше программирование
• TDD: методология разработки, которая изменила мою жизнь
• Деконструкция TDD
• Почему Test Driven Development (TDD) лучше всего подходит для надежного программирования
• Почему я люблю TDD
•  TDD в Android
• Да, TDD вас замедляет
• Создание чистого приложения «Game of Life» на Flutter с использованием гексагональной архитектуры и TDD
• Почему Test Driven Development (TDD) лучше всего подходит для надежного программирования

Если вы нашли опечатку — выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor. ru.

TDD — разработка через тестирование

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

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

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

Цикл разработки по TDD

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

Эта методология позволяет добиться создания пригодного для автоматического тестирования приложения и очень хорошего покрытия кода тестами, так как ТЗ переводится на язык автоматических тестов, то есть всё, что программа должна делать, проверяется. Также TDD часто упрощает программную реализацию: так как исключается избыточность — если компонент проходит тест, то он считается готовым. Если же существующие тесты проходят, но работает компонент не так, как ожидается, то это значит, что тесты пока не отражают всех требований и это повод добавить новые тесты.

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

Что такое разработка через тестирование (TDD)?

Добро пожаловать

ГЛОССАРИЙ

Определение

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

Его можно кратко описать следующим набором правил:

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

Ожидаемые выгоды

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

Распространенные ловушки

Типичные индивидуальные ошибки включают:

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

Типичные ошибки команды включают:

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

Истоки

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

• 1976: публикация «Надежность программного обеспечения» Гленфорда Майерса, в которой утверждается «аксиома», что «разработчик никогда не должен тестировать свой собственный код» (Dark Ages of Developer Testing)
• 1990: в дисциплине тестирования преобладают методы «черного ящика», в частности, в форме инструментов тестирования «захват и воспроизведение»
• 1991: независимое создание среды тестирования в Taligent с поразительным сходством с SUnit (источник)
• 1994: Кент Бек пишет среду тестирования SUnit для Smalltalk (источник)
• 1998: в статье об экстремальном программировании упоминается, что «обычно мы сначала пишем тест» (источник)
• с 1998 по 2002 год: «Test First» преобразован в «Test Driven», в частности, на C2. com Wiki
• 2000: Имитационные объекты входят в число новых техник, разработанных в этот период (источник)
• 2003: публикация «Разработка через тестирование: на примере» Кента Бека

К 2006 году TDD является относительно зрелой дисциплиной, которая начала поощрять дальнейшие инновации, производные от нее, такие как ATDD или BDD).

Признаки использования

• «покрытие кода» — распространенный подход к подтверждению использования TDD; в то время как высокий охват не гарантирует надлежащего использования TDD, охват ниже 80%, вероятно, указывает на недостатки в освоении командой TDD
• Журналы управления версиями должны показывать, что тестовый код проверяется каждый раз, когда регистрируется код продукта, в примерно сопоставимых количествах

Уровни навыков

Новичок

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

Промежуточный

• практикует «исправление ошибок через тестирование»: при обнаружении дефекта пишет тест, выявляющий дефект перед исправлением
• возможность разложить функцию составной программы на последовательность нескольких модульных тестов, которые необходимо написать
• знает и может назвать несколько приемов написания тестов (например, «при тестировании рекурсивного алгоритма сначала напишите тест для случая завершения рекурсии»)
• возможность выделять повторно используемые элементы из существующих модульных тестов, создавая инструменты тестирования для конкретных ситуаций

Продвинутый уровень

• способность сформулировать «дорожную карту» запланированных модульных тестов для макроскопических функций (и пересмотреть ее при необходимости)
• способен «протестировать» различные парадигмы проектирования: объектно-ориентированный, функциональный, событийный
• способен «протестировать» различные технические области: вычисления, пользовательские интерфейсы, постоянный доступ к данным…

Дополнительная литература

Разработка через тестирование: на примере, Кент Бек

Ресурсы Agile Alliance

Сообщите нам, если нам потребуется пересмотреть этот термин Глоссария.

Введение в разработку через тестирование (TDD)

Разработка через тестирование (TDD) (Бек
2003 г.;
Астельс
2003), является
эволюционный подход к разработке, который сочетает в себе разработку «сначала тестирование», где
вы пишете тест до того, как напишете ровно столько производственного кода, чтобы выполнить это
испытание и
рефакторинг.
Какова основная цель TDD?
С одной точки зрения, целью TDD является спецификация, а не проверка (Martin,
Ньюкирк и Кесс, 2003).
Другими словами, это один из способов продумать свое
Требования или дизайн
прежде чем вы напишете свой функциональный код (подразумевая, что TDD является важным

гибкие требования и

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

Содержание

1. Что такое TDD?
2. TDD и традиционное тестирование
3. TDD и документация
4. Разработка базы данных через тестирование
5. Масштабирование TDD с помощью Agile Model-Driven Development (AMDD)
6. Почему TDD?
7. Мифы и заблуждения
8. Кто на самом деле этим занимается?
9. Резюме
10. Инструменты

Фигура
1. Этапы разработки с первым тестом (TFD).

Мне нравится описывать TDD с помощью этой простой формулы:

TDD = Рефакторинг + TFD.

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

Рис. 2. Как приемка TDD и
разработчики TDD работают вместе.

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

обобщающие специалисты предпочтительнее специалистов).
Основополагающее предположение TDD заключается в том, что у вас есть
доступный для вас фреймворк. Для принятия
Специалисты по TDD будут использовать такие инструменты, как
Фитнес или RSpec
и для разработчиков TDD Agile
разработчики программного обеспечения часто используют семейство инструментов xUnit с открытым исходным кодом, например JUnit.
или VBUnit, хотя коммерческие инструменты
тоже годные варианты. Без таких
средствами TDD практически невозможно.
Фигура
3 представлена ​​диаграмма состояний UML, показывающая, как люди обычно работают с такими инструментами. Эту схему мне предложил
Кейт Рэй.

Рисунок 3. Тестирование через xUnit
Рамки.

Для разработчиков это означает, что им нужно учиться
как писать эффективные модульные тесты. Бека
опыт показывает, что хорошие модульные тесты:

• Бегать быстро (у них короткие настройки, время работы и перерывы в работе).
  падения).
• Запускайте изолированно (вы должны иметь возможность изменить их порядок).
• Используйте данные, которые облегчают чтение и
  понять.
• Используйте реальные данные (например, копии производственных данных), когда
  им нужно.
• Представьте один шаг к вашей общей цели.

Как
при традиционном тестировании, чем выше профиль риска системы, тем больше
тщательно ваши тесты должны быть. Как с традиционным тестированием, так и с TDD вы не
стремясь к совершенству, вместо этого вы проверяете важность
система. Перефразируя Agile
Моделирование (AM), вы должны «целенаправленно тестировать» и знать, почему вы
тестируете что-то и до какого уровня это нужно тестировать.
Интересным побочным эффектом TDD является то, что вы достигаете 100%-го покрытия теста.
— проверяется каждая строка кода — то, что традиционное тестирование
не гарантирует (хотя и рекомендует). В
в целом, я думаю, можно с уверенностью сказать, что хотя TDD и является спецификацией
метод, ценным побочным эффектом является то, что он приводит к значительному
лучшее тестирование кода, чем традиционные методы.

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

исполняемые спецификации.

Достаточно ли документации для тестов? Скорее всего, нет, но они составляют важную его часть.
Например, вы, вероятно, обнаружите, что вам по-прежнему нужны пользовательские, системные
обзор, операции и вспомогательная документация.
Вы даже можете обнаружить, что вам требуется сводная документация с обзором
бизнес-процесс, который поддерживает ваша система.
Когда вы подходите к документации непредвзято, я подозреваю, что вы
вы обнаружите, что эти два типа тестов охватывают большую часть вашей документации.
потребности разработчиков и заинтересованных сторон бизнеса. Кроме того, они являются
прекрасный пример АМ
Одинокий
Практика получения исходной информации и важная часть ваших общих усилий по
оставаться как
максимально гибкой в ​​отношении документации.

В
на момент написания этой статьи важный вопрос задавали в Agile
сообщества: «Может ли TDD работать для разработки, ориентированной на данные?» Если вы посмотрите на процесс, изображенный на рис.
1 важно отметить, что ни один из шагов не определяет объектное программирование
языки, такие как Java или C#, даже если это среды, в которых TDD
обычно используется в. Почему вы не могли
написать тест, прежде чем вносить изменения в схему базы данных?
Почему вы не могли внести изменения, запустить тесты и провести рефакторинг схемы?
как требуется? Мне кажется, что
вам нужно только выбрать работать таким образом.

Мой
думаю, что в ближайшей перспективе база данных TDD или, возможно, база данных, управляемая тестированием
Дизайн (TDDD) не будет работать так гладко, как
приложение ТДД. Первый
проблема — инструментальная поддержка. Несмотря на то что
инструменты модульного тестирования, такие как DBUnit,
теперь они доступны, но на момент написания этой статьи они все еще являются новой технологией.
Немного
инженеры данных улучшают качество проводимого ими тестирования, но я еще не
видел, как кто-нибудь использует подход TDD к разработке баз данных. Одна из проблем заключается в том, что инструменты модульного тестирования все еще не очень хорошо приняты в данных.
сообщество, хотя оно и меняется, поэтому я ожидаю, что в следующем
Через несколько лет база данных TDD будет расти. Второй,
Концепция чего-либо
эволюционное развитие является новым для многих специалистов по данным и, поскольку
в результате мотивация для использования подхода TDD еще не укоренилась.
Эта проблема влияет на характер инструментов, доступных для обработки данных.
профессионалы — потому что
серийное мышление по-прежнему доминирует в
большинство инструментов традиционного сообщества данных не поддерживают эволюционное развитие.
Я надеюсь, что производители инструментов поймут эту смену парадигмы, но
я ожидаю, что вместо этого нам нужно будет разработать инструменты с открытым исходным кодом.
В-третьих, по моему опыту, большинство людей, работающих с данными, кажутся
предпочесть модельный, а не тестовый подход.
Одна из причин этого, вероятно, заключается в том, что подход, основанный на тестировании, не применялся.
широко рассматривался до сих пор, другой причиной может быть то, что многие данные
профессионалы, вероятно, мыслят визуально и поэтому предпочитают моделировать
подход.

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

Рис. 4. Гибкая модель, управляемая
Жизненный цикл разработки (AMDD).

Сравнение TDD и AMDD:

• TDD сокращает цикл обратной связи при программировании, тогда как AMDD
  сокращает петлю обратной связи моделирования.

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

• TDD способствует разработке качественного кода
  тогда как AMDD способствует качественному общению с вашими заинтересованными сторонами и
  другие разработчики.

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

• TDD «разговаривает» с программистами, тогда как AMDD говорит с
  бизнес-аналитики, заинтересованные стороны и специалисты по данным.

• TDD обеспечивает очень мелкозернистый бетон обратной связи
  порядка минут, в то время как AMDD обеспечивает словесную обратную связь по порядку
  минут (конкретная обратная связь требует, чтобы разработчики следовали практике
  Он с кодом и, таким образом, становится зависимым от методов, не связанных с AM).

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

• TDD не ориентирован на визуальное восприятие, тогда как AMDD визуально
  ориентированный.

• Оба метода являются новыми для традиционных разработчиков и
  поэтому может представлять для них угрозу.

• Оба метода поддерживают эволюционное развитие.

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

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

Существенным преимуществом TDD является то, что он позволяет
небольшие шаги при написании программного обеспечения. Этот
это практика, которую я продвигаю годами, потому что она гораздо более продуктивна
чем пытаться кодировать большими шагами. За
Например, предположим, что вы добавили новый функциональный код, скомпилировали и протестировали его.
Скорее всего, ваши тесты будут нарушены дефектами, которые
существуют в новом коде. это много
легче найти, а затем исправить эти дефекты, если вы написали две новые строки
код, чем две тысячи. Подразумевается, что чем быстрее ваш компилятор и
набор регрессионных тестов, тем привлекательнее использовать меньшие и
меньшие шаги. я вообще предпочитаю
добавить несколько новых строк функционального кода, обычно менее десяти, прежде чем я
перекомпилируйте и перезапустите мои тесты.
Я думаю
Боб Мартин хорошо сказал: «Написание модульного теста
является скорее актом проектирования, чем проверки.
Это также больше акт документирования, чем проверки.
Процесс написания модульного теста закрывает огромное количество отзывов.
петли, наименьшая из которых относится к проверке функции».
Первая реакция многих людей на agile-методы:
что они подходят для небольших команд, возможно, с участием нескольких человек для
несколько месяцев, но что они не будут работать для «настоящих» инициатив, которые
намного больше. Это
просто неправда. Бек (2003)
отчеты о работе в системе Smalltalk с полностью основанным на тестировании подходом
на что ушло 4 года и 40 человеко-лет усилий, в результате чего было напечатано 250 000 строк
функциональный код и 250 000 строк тестового кода.
Выполняется 4000 тестов менее чем за 20 минут с полным набором
проводится несколько раз в день. Несмотря на то что
существуют более крупные системы, я лично работал с системами, в которых
было задействовано несколько сотен человеко-лет, ясно, что TDD работает
для систем хорошего размера.

Существует несколько распространенных мифов и заблуждений, которые люди
есть относительно TDD, который я хотел бы прояснить, если это возможно. Таблица 1 перечисляет эти мифы и описывает реальность.
Таблица 1. Развенчание мифов и
заблуждения относительно TDD.

Миф	Реальность
Вы создаете набор 100% регрессионных тестов	Хотя это звучит как хорошая цель, и это так, к сожалению, нереально по нескольким причинам: У меня могут быть многоразовые компоненты/фреймворки/. .. которые я скачал или купил какие не поставляется с набором тестов и, возможно, даже с исходным кодом. Хотя я могу и часто делаю тесты черного ящика, которые проверяют интерфейс компонента эти тесты не будут полностью проверять компонент. Пользовательский интерфейс очень сложно протестировать. Хотя инструменты тестирования пользовательского интерфейса действительно существуют, не все владеет ими, и иногда ими трудно пользоваться. Обычный стратегия состоит в том, чтобы не автоматизировать тестирование пользовательского интерфейса, а вместо этого надеюсь что Усилия по пользовательскому тестированию охватывают этот важный аспект вашей системы. Не идеальный подход, но все же распространенный. Некоторые разработчики в команде могут не иметь навыки тестирования. Регрессионное тестирование базы данных — довольно новая концепция, и она еще не хорошо поддерживается инструментами. Возможно, я работаю над унаследованной системы и, возможно, еще не удосужились написать тесты для некоторых устаревших функций.
Модульные тесты составляют 100% спецификаций вашего проекта	Люди, плохо знакомые с гибкой разработкой программного обеспечения, или люди, утверждающие, что они гибкие но кто на самом деле не является, или, возможно, люди, которые никогда не были вовлечены с реальной agile-командой, иногда говорят это. Реальность заключается в том, что модульный тест составляет значительную часть дизайн спецификация, аналогично приемочные тесты составляют значительную часть вашего спецификации требований, но это еще не все. Как показано на рис. 4, агилисты на самом деле модель (и документа, если уж на то пошло), просто мы очень хорошо разбираемся в том, как мы делаем это. Потому что вы думаете о производственном коде, прежде чем написать его, вы эффективно выполняете детальное проектирование, как я очень предлагаю прочитать мой Информация из одного источника: Agile-практика для эффективного документирования статья.
Вам нужно только модульное тестирование	Для всех систем, кроме самых простых, это полностью ЛОЖЬ. Agile-сообщество очень четко понимает необходимость хозяин другое тестирование методы.
TDD достаточно для тестирования	TDD, на модульном тесте/тесте разработчика, а также на уровень тестирования клиента, является лишь частью ваших общих усилий по тестированию. В лучшем случае это включает в себя ваши усилия по подтверждающему тестированию, но как Рисунок 5 показывает, что вы также должны быть обеспокоены независимые усилия по тестированию, которые выходят за рамки этого. Видеть Agile Testing and Quality Strategies: реальность важнее риторики, подробнее о гибких стратегиях тестирования.
TDD не масштабируется	Отчасти это правда, хотя отчасти это легко преодолеть. К проблемам масштабируемости TDD относятся: Ваш набор тестов слишком долго выполняется . Это распространенная проблема с не менее распространенными решениями. Во-первых, разделите набор тестов на два или более компонентов. Один тест набор содержит тесты для новой функциональности, которую вы в настоящее время работает, другой набор тестов содержит все тесты. Вы регулярно запускаете первый набор тестов, перенося старые тесты для зрелые части вашего производственного кода в общий набор тестов, как соответствующий. Общий набор тестов выполняется в фоновом режиме, часто на отдельной машине(ах) и/или ночью. В масштабе Я видел несколько уровней набора тестов — тесты песочницы для разработки. которые выполняются за 5 минут или меньше, интеграционные тесты, которые выполняются за несколько часов или меньше, набор тестов, который выполняется в течение многих часов или даже несколько дней, которые запускаются реже. У меня в одной команде видели набор тестов, который работает в течение нескольких месяцев (в центре внимания нагрузочное/стресс-тестирование и доступность). Во-вторых, бросить некоторые аппаратные средства в проблеме. Не все разработчики знают, как тестировать . Часто это так, так что проведите им соответствующую подготовку и получите они объединяются с людьми с навыками модульного тестирования. Любой, кто жалуется на эту проблему чаще, чем нет, кажется, ищет в качестве предлога не принимать TDD. Возможно, не все используют подход TDD . Использование TDD-подхода к разработке — это то, на что ориентируется каждый. команда должна согласиться сделать. Если некоторые люди этого не делают, затем в порядке предпочтения: им либо нужно начинать, им нужно быть мотивированным покинуть команду, или ваша команда должна отказаться от TDD.

Рис. 5. Тестирование во время строительных спринтов (нажмите, чтобы увеличить).

К сожалению, скорость внедрения TDD не так высока, как хотелось бы.
Рисунок 6, на котором обобщены результаты
в

2010 Насколько ты проворный? опрос, дает представление о том, какая проверка
стратегии, которым следуют команды, претендующие на гибкость. Я подозреваю
что показатели принятия, указанные для TDD разработчика и принятия TDD, составляют 53% и
44% соответственно, гораздо более реалистичны, чем те, о которых сообщалось в
мой

Обзор разработки через тестирование (TDD) 2008 г.

Рис. 6. Проверка agile-команд
их собственная работа.

Разработка через тестирование (TDD) — это метод разработки, при котором вы должны
сначала напишите тест, который не работает, прежде чем писать новый функциональный код.
Гибкие разработчики программного обеспечения быстро внедряют TDD для разработки.
исходного кода приложения и даже используется Agile-инженерами данных для
база данных
разработка.
TDD следует рассматривать как дополнение к Agile.
Подходы Model Driven Development (AMDD), и эти два подхода могут и должны
используются вместе. TDD не заменяет
традиционное тестирование, вместо этого оно определяет проверенный способ обеспечения эффективности
тестирование. Побочным эффектом TDD является
что полученные тесты являются рабочими примерами для вызова кода, тем самым
предоставление рабочей спецификации кода. Мой опыт показывает, что TDD работает
невероятно хорошо на практике, и это то, что все программное обеспечение
разработчикам следует подумать о принятии.

This entry was posted in Популярное