Що таке Test Driven Development (TDD)? приклад

Автор: Томас Гамільтон Томас Гамільтон
Hours оновлений

Що таке Test Driven Development (TDD)?

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

Розробка, орієнтована на тестування, починається з проектування та розробки тестів для кожної невеликої функціональності програми. Фреймворк TDD наказує розробникам писати новий код, лише якщо автоматичний тест не вдався. Це дозволяє уникнути дублювання коду. Повна форма TDD – це тестова розробка.

Тестовий рух розвитку

Проста концепція TDD полягає в написанні та виправленні невдалих тестів перед написанням нового коду (перед розробкою). Це допомагає уникнути дублювання коду, оскільки ми пишемо невелику кількість коду за раз, щоб пройти тести. (Тести — це не що інше, як умови вимог, які ми повинні перевірити, щоб їх виконати).

Розробка на основі тестування — це процес розробки та запуску автоматизованого тестування перед фактичною розробкою програми. Тому TDD іноді також називають Test First Development.

Як виконати тест TDD

Наступні кроки визначають, як виконати тест TDD,

  1. Додайте тест.
  2. Запустіть усі тести та подивіться, чи не вдасться якісь нові тести.
  3. Напишіть якийсь код.
  4. Запуск тестів і рефакторинг коду.
  5. Повторіть.
Виконайте тест TDD
П'ять кроків розробки, керованої тестуванням

Визначає цикл TDD

  1. Написати контрольну роботу
  2. Змусити його працювати.
  3. Змініть код, щоб зробити його правильним, тобто Refactor.
  4. Повторіть процес.

Деякі пояснення щодо TDD:

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

TDD Vs. Традиційне тестування

Нижче наведено основні відмінності між розробкою, орієнтованою на тестування, і традиційним тестуванням:

Підхід TDD – це в першу чергу техніка специфікації. Це гарантує, що ваш вихідний код ретельно перевірено на підтверджувальному рівні.

  • При традиційному тестуванні успішний тест виявляє один або кілька дефектів. Це те саме, що TDD. Коли тест проходить невдало, ви досягли прогресу, оскільки знаєте, що вам потрібно вирішити проблему.
  • TDD гарантує, що ваша система дійсно відповідає встановленим для неї вимогам. Це допомагає зміцнити вашу впевненість у вашій системі.
  • У TDD більше уваги приділяється робочому коду, який перевіряє, чи буде тестування працювати належним чином. У традиційному тестуванні більше уваги приділяється дизайну тестового випадку. Чи покаже тест належне/неналежне виконання програми для виконання вимог.
  • У TDD ви досягаєте 100% тесту покриття. Кожен рядок коду перевіряється, на відміну від традиційного тестування.
  • Поєднання як традиційного тестування, так і TDD призводить до важливості тестування системи, а не вдосконалення системи.
  • In Гнучке моделювання (AM), вам слід «тестувати з певною метою». Ви повинні знати, навіщо ви тестуєте щось і який рівень потрібно перевірити.

СТАТТІ ПО ТЕМІ

Що таке TDD прийняття та TDD розробника

Існує два рівні TDD

  1. TDD прийняття (ATDD): За допомогою ATDD ви пишете єдиний приймальний тест. Цей тест відповідає вимогам специфікації або задовольняє поведінку системи. Після цього напишіть лише стільки робочого/функціонального коду, щоб виконати цей приймальний тест. Приймальний тест зосереджується на загальній поведінці системи. ATDD також був відомий як Поведінковий розвиток (BDD).
  2. Розробник TDD: За допомогою Developer TDD ви пишете єдиний тест розробника, тобто одиничний тест, а потім лише достатню кількість робочого коду для виконання цього тесту. Модульне тестування зосереджується на кожній дрібній функціональності системи. Розробник TDD називається просто as TDD.Основна мета ATDD і TDD — визначити детальні вимоги до виконуваного рішення для вашого рішення на основі точного часу (JIT). JIT означає врахування лише тих вимог, які необхідні системі. Так підвищити ефективність.

TDD прийняття та TDD розробника

Масштабування TDD за допомогою Agile Model Driven Development (AMDD)

TDD дуже добре справляється з детальною специфікацією та перевіркою. Він не в змозі продумати більші питання, такі як загальний дизайн, використання системи або інтерфейс користувача. AMDD вирішує проблеми Agile-масштабування, яких не вирішує TDD.

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

Життєвий цикл AMDD

Життєвий цикл AMDD

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

На малюнку вище кожен квадрат представляє діяльність із розробки.

Прогнозування є одним із процесів TDD прогнозування/уявлення тестів, які будуть виконуватися протягом першого тижня проекту. Основна мета візіонінгу полягає в тому, щоб визначити обсяг системи та архітектуру системи. Вимоги високого рівня та моделювання архітектури виконуються для успішного проектування.

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

Ітерація 0: Уявлення

Існує два основних субактиви.

  1. Передбачення початкових вимог.Визначення вимог високого рівня та обсягу системи може зайняти кілька днів. Основна увага приділяється дослідженню моделі використання, початкової моделі домену та моделі інтерфейсу користувача (UI).
  2. Початковий Archiтектурне бачення. Для визначення архітектури системи також потрібно кілька днів. Це дозволяє задати технічні напрямки для проекту. Основна увага зосереджена на вивченні технологічних діаграм, потоку інтерфейсу користувача (UI), моделей домену та випадків зміни.

Ітераційне моделювання

Тут команда повинна спланувати роботу, яка буде виконана для кожної ітерації.

  • Гнучкий процес використовується для кожної ітерації, тобто під час кожної ітерації новий робочий елемент буде додано з пріоритетом.
  • До уваги братимуться першочергові роботи. Додані робочі елементи можна будь-коли змінити пріоритети або видалити зі стосу елементів.
  • Команда обговорює, як вони збираються реалізувати кожну вимогу. Для цього використовується моделювання.
  • Аналіз моделювання та проектування виконуються для кожної вимоги, яка буде реалізована для цієї ітерації.

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

Це також відоме як своєчасне моделювання.

  • Тут сеанс моделювання включає команду з 2/3 членів, які обговорюють проблеми на папері чи дошці.
  • Один член команди попросить іншого змоделювати разом з ним. Цей сеанс моделювання триватиме приблизно від 5 до 10 хвилин. Де члени команди збираються разом, щоб поділитися дошкою/папером.
  • Вони досліджують проблеми, поки не знайдуть головну причину проблеми. Якраз вчасно, якщо один член команди визначить проблему, яку він/вона хоче вирішити, тоді він/вона швидко скористається допомогою інших членів команди.
  • Потім інші члени групи досліджують проблему, а потім усі продовжують, як і раніше. Це також називається стоячим моделюванням або сеансами контролю якості клієнтів.

Розробка, керована тестуванням (TDD)

  • Це сприяє підтверджуючому тестуванню коду програми та детальної специфікації.
  • І приймальний тест (детальні вимоги), і тести розробника (модульний тест) є вхідними для TDD.
  • TDD робить код простішим і зрозумілішим. Це дозволяє розробнику зберігати менше документації.

Відгуки

  • Це необов'язково. Він включає перевірку коду та огляд моделей.
  • Це можна зробити для кожної ітерації або для всього проекту.
  • Це хороший варіант, щоб залишити відгук про проект.

Test Driven Development (TDD) Vs. Гнучка розробка на основі моделі (AMDD)

TDD AMDD
TDD скорочує цикл зворотного зв'язку програмування AMDD скорочує цикл зворотного зв'язку моделювання.
TDD — детальна специфікація AMDD працює для більших проблем
TDD сприяє розробці високоякісного коду AMDD сприяє високоякісному спілкуванню із зацікавленими сторонами та розробниками.
TDD розмовляє з програмістами AMDD розмовляє з Бізнес-аналітик, зацікавлені сторони та спеціалісти з даних.
TDD не візуально орієнтований AMDD візуально орієнтований
TDD має обмежений обсяг програмних робіт AMDD має широку сферу дії, включаючи зацікавлених сторін. Це передбачає роботу над загальним розумінням
Обидва підтримують еволюційний розвиток ---------------

TDD Frameworks

Ось список найкращих фреймворків розробки, керованих тестуванням (TDD).

  1. Юніт
  2. TestNG
  3. csUnit і NUnit
  4. Rspec

Тепер давайте навчимося розробці, керованій тестуванням, на прикладі.

Приклад TDD

У цьому прикладі тестової розробки ми визначимо пароль класу. Для цього класу ми спробуємо задовольнити наступні умови.

Умова для прийняття пароля:

  • Пароль має містити від 5 до 10 символів.

Спочатку в цьому прикладі TDD ми пишемо код, який відповідає всім наведеним вище вимогам.

Приклад TDD

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

Приклад TDD

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

Результат пройдено, як показано нижче;

Вихід:

Приклад TDD

Сценарій 2: Тут ми бачимо, що в методі TestPasswordLength () немає необхідності створювати екземпляр класу PasswordValidator. Примірник означає створення об'єкт класу для посилання на члени (змінні/методи) цього класу.

Приклад TDD

Ми видалимо з коду клас PasswordValidator pv = new PasswordValidator (). Ми можемо подзвонити isValid () метод безпосередньо шляхом PasswordValidator. IsValid («Abc123»). (Див. зображення нижче)

Тому ми проводимо рефакторинг (змінюємо код), як показано нижче:

Приклад TDD

Сценарій 3: після рефакторингу вихідні дані показують невдалий статус (див. зображення нижче). Це тому, що ми видалили екземпляр. Тому немає посилання на нестатичний метод isValid ().

Приклад TDD

Отже, нам потрібно змінити цей метод, додавши «статичне» слово перед Boolean як загальнодоступний статичний boolean isValid (рядковий пароль). Рефакторинг класу PasswordValidator (), щоб видалити вищезазначену помилку, щоб пройти тест.

Приклад TDD

вихід:

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

Приклад TDD

Переваги TDD

Нижче наведено основні переваги тестової розробки в інженерії програмного забезпечення:

Раннє повідомлення про помилку.

  • Розробники тестують свій код, але у світі баз даних це часто складається з ручних тестів або одноразових сценаріїв. Використовуючи TDD, ви з часом створюєте набір автоматизованих тестів, які ви та будь-який інший розробник можете повторно запустити за бажанням.

Кращий, чистіший і розширюваний код.

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

Впевненість у рефакторингу

  • Якщо ви виконуєте рефакторинг коду, у ньому можуть виникнути розриви. Отже, маючи набір автоматизованих тестів, ви можете виправити ці збої перед випуском. Буде надано відповідне попередження, якщо будуть виявлені порушення під час використання автоматизованих тестів.
  • Використання TDD має призвести до швидшого, більш розширюваного коду з меншою кількістю помилок, який можна оновлювати з мінімальними ризиками.

Добре підходить для командної роботи

  • За відсутності будь-кого з членів команди інші члени команди можуть легко підібрати код і працювати над ним. Це також допомагає обмінюватися знаннями, тим самим підвищуючи ефективність команди в цілому.

Добре для розробників

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

Підсумки

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

Вам може сподобатися: