Що таке тестова розробка (TDD)? Підручник із прикладом

Зміст:

Anonim

Тестова розробка

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

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

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

Тестова розробка - це процес розробки та запуску автоматизованого тестування перед фактичною розробкою програми. Отже, TDD іноді також називають тестом першої розробки.

У цьому підручнику ви дізнаєтесь більше про

  • Як виконати тест TDD
  • TDD проти Традиційне тестування
  • Що таке TDD прийняття та TDD розробника
  • Масштабування TDD за допомогою Agile Model Driven Development (AMDD)
  • Тестова розробка (TDD) проти. Agile Model Driven Development (AMDD)
  • Приклад TDD
  • Переваги TDD

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

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

  1. Додайте тест.
  2. Запустіть усі тести і перевірте, чи не вдається якийсь новий тест.
  3. Напишіть код.
  4. Запустіть тести та код рефактора.
  5. Повторити.

Цикл TDD визначає

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

Деякі роз’яснення щодо TDD:

  • TDD не стосується ні "Тестування", ні "Дизайну".
  • TDD не означає "написати деякі тести, а потім побудувати систему, яка проходить тести.
  • TDD не означає "робити багато тестувань".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Ітерація 0: Передбачення

Є дві основні суб-активації.

  1. Початкові вимоги, що передбачаються.

    Визначення вимог високого рівня та сфери застосування системи може зайняти кілька днів. Основна увага приділяється дослідженню моделі використання, моделі початкового домену та моделі інтерфейсу користувача (UI).

  2. Початкове архітектурне планування.

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

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

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

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

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

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

Тестова розробка (TDD) проти. Agile Model Driven Development (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 ().

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

Вихід:

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

Переваги TDD

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

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

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

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

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

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

Короткий зміст:

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

Ця стаття внесена Канчаном Кулкарні