Что такое Разработка через тестирование (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 часто упрощает программную реализацию: так как исключается избыточность — если компонент проходит тест, то он считается готовым. Если же существующие тесты проходят, но работает компонент не так, как ожидается, то это значит, что тесты пока не отражают всех требований и это повод добавить новые тесты.

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

Что такое разработка через тестирование? | TestDriven.io

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

TDD обычно следует циклу «красный-зеленый-рефакторинг»:

1. Добавить тест в набор тестов
2. (красный) Запустите все тесты, чтобы убедиться, что новый тест не прошел
3. (зеленый) Напишите достаточно кода, чтобы пройти этот единственный тест
4. Запустить все тесты
5. (Рефакторинг) Улучшить исходный код, сохранив тесты зелеными
6. Повторить

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

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

Преимущества

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

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

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

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

Итеративный процесс

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

Подходы

Существует два основных подхода к TDD — Inside Out и Outside In.

Наизнанку

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

Снаружи Внутри

Подход Outside In (или Лондонской школы TDD или Mockist) фокусируется на поведении пользователя. Тестирование начинается на самом внешнем уровне, и детали появляются по мере того, как вы продвигаетесь вперед. Этот подход в значительной степени зависит от имитации и заглушки внешних зависимостей. Как правило, его сложнее освоить, но он помогает убедиться, что код соответствует общим потребностям бизнеса. Дизайн происходит на красной стадии.

Какой подход лучше?

Ни то, ни другое. Попробуйте каждый из них. Используйте их, когда это уместно.

Часто проще использовать подход Outside In при работе со сложными приложениями, которые имеют большое количество быстро меняющихся внешних зависимостей (например, микросервисы). Небольшие монолитные приложения часто лучше подходят для подхода Inside Out.

Подход Outside In также имеет тенденцию лучше работать с интерфейсными приложениями, поскольку код настолько близок к конечному пользователю. Дополнительные сведения см. в разделе Современное внешнее тестирование с помощью Cypress.

Часто задаваемые вопросы

Почему так важно увидеть, что тест провален?

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

Проще говоря, неудачный тест:

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

Что изучать и практиковать Разработка через тестирование? Ознакомьтесь с курсами TestDriven.

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

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

ГЛОССАРИЙ

Определение

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

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

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

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

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

Типичные ошибки

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

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

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

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

Истоки

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

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

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