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

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

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

Разработка через тестирование начинается с проектирования и разработки тестов для каждой небольшой функциональности приложения. TDD предписывает разработчикам писать новый код только в том случае, если автоматический тест не прошел. Это позволяет избежать дублирования кода. Полная форма TDD - это разработка через тестирование.

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

Разработка через тестирование - это процесс разработки и запуска автоматического тестирования перед фактической разработкой приложения. Следовательно, TDD иногда также называют Test First Development.

В этом руководстве вы узнаете больше о-

Как выполнить тест TDD
TDD Vs. Традиционное тестирование
Что такое прием TDD и Developer TDD
Масштабирование TDD с помощью Agile Model Driven Development (AMDD)
Разработка через тестирование (TDD) Vs. Разработка на основе гибких моделей (AMDD)
Пример TDD
Преимущества TDD

Как выполнить тест TDD

Следующие шаги определяют, как выполнять тест TDD,

Добавить тест.
Запустите все тесты и посмотрите, не завершится ли какой-либо новый тест.
Напишите код.
Запустите тесты и выполните рефакторинг кода.
Повторение.

Цикл TDD определяет

Написать тест
Заставь его работать.
Измените код, чтобы он был правильным, например, рефакторинг.
Повторите процесс.

Некоторые пояснения по поводу TDD:

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

TDD Vs. Традиционное тестирование

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

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

Что такое прием TDD и Developer TDD

Есть два уровня TDD

Приемочный TDD (ATDD): с ATDD вы пишете один приемочный тест. Этот тест соответствует требованиям спецификации или поведению системы. После этого напишите достаточно производственного / функционального кода для выполнения этого приемочного испытания. Приемочный тест фокусируется на общем поведении системы. ATDD также был известен как Behavioral Driven Development (BDD).
Developer TDD: с Developer TDD вы пишете единичный тест разработчика, то есть модульный тест, а затем достаточно производственного кода для выполнения этого теста. Модульный тест фокусируется на каждой мелкой функциональности системы. Разработчик TDD просто называется TDD.
Основная цель ATDD и TDD - указать подробные исполняемые требования для вашего решения на своевременной основе (JIT). JIT означает принятие во внимание только тех требований, которые необходимы в системе. Так что повышайте эффективность.

Масштабирование TDD с помощью Agile Model Driven Development (AMDD)

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

Таким образом, AMDD используется для решения более серьезных проблем.

Жизненный цикл AMDD.

В модельно-управляемой разработке (MDD) обширные модели создаются до написания исходного кода. У которых, в свою очередь, есть гибкий подход?

На приведенном выше рисунке каждое поле представляет собой деятельность по разработке.

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

Это процесс, в котором делается не подробная спецификация программного обеспечения / системы, а изучаются требования к программному обеспечению / системе, которые определяют общую стратегию проекта.

Итерация 0: предвидение

Есть две основные подактивы.

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

Итерационное моделирование:
Здесь команда должна спланировать работу, которая будет выполняться для каждой итерации.

Гибкий процесс используется для каждой итерации, т.е. во время каждой итерации новый рабочий элемент будет добавляться с приоритетом.
Будет учтена первая работа с более высоким приоритетом. Добавленные рабочие элементы могут быть изменены в приоритетном порядке или удалены из стека элементов в любое время.
Команда обсуждает, как они собираются реализовать каждое требование. Для этого используется моделирование.
Анализ и проектирование моделирования выполняется для каждого требования, которое будет реализовано на этой итерации.

Модель штурма:
Это также известно как Just in time Modeling.

Здесь в моделировании участвует команда из 2/3 членов, которые обсуждают вопросы на бумаге или доске.
Один член команды попросит другого поработать вместе с ними. Этот сеанс моделирования займет от 5 до 10 минут. Где члены команды собираются вместе, чтобы поделиться доской / бумагой.
Они исследуют проблемы до тех пор, пока не найдут основную причину проблемы. Как раз вовремя, если один из членов команды определяет проблему, которую он / она хочет решить, он / она быстро воспользуется помощью других членов команды.
Затем другие члены группы исследуют проблему, а затем все продолжают, как прежде. Это также называется стоячим моделированием или сессиями контроля качества клиентов.

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

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

Обзоры.

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

Разработка через тестирование (TDD) Vs. Разработка на основе гибких моделей (AMDD)

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

Пример TDD

В этом примере мы определим пароль класса. Для этого класса мы постараемся выполнить следующие условия.

Условие принятия пароля:

Пароль должен содержать от 5 до 10 символов.

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

Сценарий 1. Для запуска теста мы создаем класс PasswordValidator ();

Мы запустим над классом TestPassword ();

Выход ПРОЙДЕН, как показано ниже;

Выход :

Сценарий 2 : Здесь мы видим, что в методе TestPasswordLength () нет необходимости создавать экземпляр класса PasswordValidator. Экземпляр означает создание объекта класса для ссылки на члены (переменные / методы) этого класса.

Мы удалим из кода класс PasswordValidator pv = new PasswordValidator (). Мы можем вызвать метод isValid () напрямую с помощью PasswordValidator. IsValid («Abc123») . (См. Изображение ниже)

Итак, мы проводим рефакторинг (меняем код), как показано ниже:

Сценарий 3. После рефакторинга в выходных данных отображается состояние ошибки (см. Изображение ниже), это связано с тем, что мы удалили экземпляр. Таким образом, нет ссылки на нестатический метод isValid ().

Поэтому нам нужно изменить этот метод, добавив «статическое» слово перед логическим значением в качестве общедоступного статического логического значения isValid (строковый пароль). Рефакторинг класса PasswordValidator () для удаления указанной выше ошибки и прохождения теста.

Выход:

После внесения изменений в класс PassValidator (), если мы запустим тест, результат будет ПРОЙДЕН, как показано ниже.

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

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

Резюме:

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

Эта статья предоставлена Канчаном Кулкарни