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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ниже приведено основное различие между разработкой через тестирование и традиционным тестированием:

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

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

Что такое TDD принятия и TDD разработчика

Существует два уровня TDD.

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

Масштабирование TDD с помощью гибкой разработки на основе моделей (AMDD)

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

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

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

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

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

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

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

Итерация 0: Представление

Есть две основные субактивации.

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

Итерационное моделирование

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

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

Модельный штурм

Это также известно как моделирование «точно в срок».

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

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

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

Отзывы

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

Разработка через тестирование (TDD) против. Гибкая разработка на основе моделей (AMDD)

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

TDD-фреймворки

Вот список лучших сред разработки через тестирование (TDD).

Юнит
TestNG
csUnit и NUnit
Rspec

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

Пример ТДД

Здесь, в этом примере Test Driven Development, мы определим пароль класса. Для этого класса мы попытаемся удовлетворить следующим условиям.

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

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

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

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

Мы запустим выше класс TestPassword();

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

Результат:

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

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

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

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

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

Вывод:

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

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

Ниже приведены основные преимущества разработки через тестирование в программной инженерии:

Раннее уведомление об ошибке.

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

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

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

Уверенность в рефакторинге

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

Хорошо для командной работы

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

Хорошо для разработчиков

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

Резюме

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

Вы могли бы: