Шта је тест покретани развој (ТДД)? Водич са примером

Преглед садржаја:

Anonim

Тест Дривен Девелопмент

Тест Дривен Девелопмент (ТДД) је приступ развоју софтвера у којем се развијају тест случајеви да би се прецизирало и потврдило шта ће код радити. Једноставно речено, прво се креирају и тестирају примери за сваку функционалност, а ако тест не успе, онда се пише нови код како би се тест прошао и учинио код једноставним и без грешака.

Тест-Дривен Девелопмент почиње са дизајнирањем и развојем тестова за сваку мању функционалност апликације. ТДД налаже програмерима да напишу нови код само ако аутоматизовани тест није успео. Ово избегава дуплирање кода. Пуни облик ТДД-а је развој заснован на тестовима.

Једноставан концепт ТДД-а је писање и исправљање неуспелих тестова пре писања новог кода (пре развоја). Ово помаже у избегавању дуплицирања кода јер истовремено пишемо малу количину кода како бисмо прошли тестове. (Испитивања нису ништа друго до услови које морамо тестирати да бисмо их испунили).

Тест-Дривен Девелопмент је процес развијања и покретања аутоматизованог теста пре стварног развоја апликације. Отуда се ТДД понекад назива и Тест Фирст Девелопмент.

У овом упутству ћете научити више о-

  • Како се врши ТДД тест
  • ТДД вс. Традиционално тестирање
  • Шта је прихватање ТДД и ТДД програмера
  • Скалирање ТДД-а помоћу агилног развоја вођеног моделом (АМДД)
  • Тест Дривен Девелопмент (ТДД) вс. Агиле Модел Дривен Девелопмент (АМДД)
  • Пример ТДД
  • Предности ТДД-а

Како се врши ТДД тест

Следећи кораци дефинишу како се врши ТДД тест,

  1. Додајте тест.
  2. Покрените све тестове и погледајте да ли било који нови тест не успе.
  3. Напишите неки код.
  4. Покрените тестове и Рефацтор код.
  5. Понављање.

ТДД циклус дефинише

  1. Напишите тест
  2. Нека трчи.
  3. Промените код да га исправите, тј. Рефацтор.
  4. Поновите поступак.

Неколико појашњења о ТДД-у:

  • ТДД се не односи ни на „Тестирање“ ни на „Дизајн“.
  • ТДД не значи „напишите неке тестове, а затим изградите систем који пролази тестове.
  • ТДД не значи „уради пуно тестирања“.

ТДД вс. Традиционално тестирање

ТДД приступ је првенствено техника спецификације. Осигурава да се ваш изворни код темељито тестира на потврдном нивоу.

  • Традиционалним испитивањем успешан тест проналази један или више недостатака. То је исто као ТДД. Када тест не успе, напредовали сте јер знате да треба да решите проблем.
  • ТДД осигурава да ваш систем заиста испуњава захтеве који су за њега дефинисани. Помаже у изградњи вашег поверења у ваш систем.
  • У ТДД-у је већи фокус на производном коду који проверава да ли ће тестирање радити исправно. У традиционалном тестирању, већи фокус је на дизајну тест кутија. Да ли ће тест показати правилно / неправилно извршавање апликације како би се испунили захтеви.
  • У ТДД-у постижете тест покривености од 100%. Свака појединачна линија кода је тестирана, за разлику од традиционалног тестирања.
  • Комбинација традиционалног тестирања и ТДД доводи до важности тестирања система, а не до савршенства система.
  • У агилном моделовању (АМ), требало би да „тестирате са сврхом“. Требали бисте знати зашто нешто тестирате и који ниво треба да се тестира.

Шта је прихватање ТДД и ТДД програмера

Постоје два нивоа ТДД-а

  1. ТДД за прихватање (АТДД): Са АТДД пишете један тест за прихватање. Ово испитивање испуњава захтеве спецификације или задовољава понашање система. После тога напишите довољно производног / функционалног кода да бисте испунили тај тест прихватања. Тест прихватања фокусира се на целокупно понашање система. АТДД је такође био познат под називом Бехавиорал Дривен Девелопмент (БДД).
  2. ТДД за програмере: Са Девелопер ТДД пишете један тест за програмере, тј. Јединични тест, а затим тек толико производног кода да испуните тај тест. Јединствени тест се фокусира на сваку малу функционалност система. ТДД програмера једноставно се назива ТДД.

    Главни циљ АТДД-а и ТДД-а је прецизирање детаљних, извршних захтева за ваше решење на основу тачног времена (ЈИТ). ЈИТ значи узимање у обзир само оних захтева који су потребни у систему. Па повећајте ефикасност.

Скалирање ТДД-а помоћу агилног развоја вођеног моделом (АМДД)

ТДД је врло добар у детаљним спецификацијама и валидацији. Не успијева размислити о већим питањима као што су укупни дизајн, употреба система или кориснички интерфејс. АМДД се бави проблемима агилног скалирања, а ТДД не.

Стога се АМДД користи за веће проблеме.

Животни циклус АМДД-а.

У развоју вођеном моделом (МДД) стварају се опсежни модели пре писања изворног кода. Који заузврат имају агилни приступ?

На горњој слици, свака кутија представља развојну активност.

Предвиђање је један од ТДД процеса предвиђања / замишљања тестова који ће се изводити током прве недеље пројекта. Главни циљ предвиђања је идентификација опсега система и архитектуре система. Захтеви високог нивоа и моделирање архитектуре су урађени за успешно предвиђање.

То је процес у којем се не ради детаљна спецификација софтвера / система, већ истраживање захтева софтвера / система који дефинише укупну стратегију пројекта.

  1. Итерација 0: Предвиђање

Постоје две главне подактиве.

  1. Предвиђање почетних захтева.

    Може бити потребно неколико дана да се утврде захтеви и опсег система на високом нивоу. Главни фокус је истраживање модела употребе, модела почетног домена и модела корисничког интерфејса (УИ).

  2. Почетно архитектонско предвиђање.

    Такође је потребно неколико дана да се идентификује архитектура система. Омогућава постављање техничких упутстава за пројекат. Главни фокус је на истраживању технолошких дијаграма, протока корисничког интерфејса (УИ), модела домена и промена случајева.

  1. Итерацијско моделирање:

    Овде тим мора да планира посао који ће се обавити за сваку итерацију.

  • Агиле процес се користи за сваку итерацију, односно током сваке итерације нови радни предмет ће бити додат са приоритетом.
  • Први већи приоритетни радови ће се узети у обзир. Додати радни предмети могу се у било ком тренутку реприоритетно уклонити или уклонити из низа предмета.
  • Тим разговара о томе како ће применити сваки захтев. У ту сврху се користи моделирање.
  • Анализа и дизајн моделирања врши се за сваки захтев који ће се применити за ту итерацију.
  1. Модел сторминг:

    Ово је такође познато као Јуст ин тиме Моделинг.

  • Овде сесија моделирања укључује тим од 2/3 члана који расправљају о питањима на папиру или табли.
  • Један члан тима ће замолити другог да се моделира с њима. Ова сесија моделирања трајаће приближно 5 до 10 минута. Тамо где се чланови тима окупљају како би делили таблу / папир.
  • Истражују проблеме док не пронађу главни узрок проблема. Тачно на време, ако један члан тима идентификује проблем који жели да реши, потражит ће брзу помоћ осталих чланова тима.
  • Остали чланови групе затим истражују проблем и онда сви настављају по старом. Такође се назива станд-уп моделирање или КА сесије купца.
  1. Тест Дривен Девелопмент (ТДД).
  • Промовише потврдно тестирање кода ваше пријаве и детаљне спецификације.
  • И тест прихватљивости (детаљни захтеви) и тест програмера (јединични тест) су улазни подаци за ТДД.
  • ТДД чини код једноставнијим и јаснијим. Омогућава програмеру да одржава мање документације.
  1. Коментара.
  • Ово није обавезно. Укључује инспекције кодова и прегледе модела.
  • То се може урадити за сваку итерацију или за цео пројекат.
  • Ово је добра опција за повратне информације о пројекту.

Тест Дривен Девелопмент (ТДД) вс. Агиле Модел Дривен Девелопмент (АМДД)

ТДД АМДД
  • ТДД скраћује програмску повратну спрегу
  • АМДД скраћује петљу повратних информација о моделирању.
  • ТДД је детаљна спецификација
  • АМДД ради на већим проблемима
  • ТДД промовише развој висококвалитетног кода
  • АМДД промовише висококвалитетну комуникацију са заинтересованим странама и програмерима.
  • ТДД разговара са програмерима
  • АМДД разговара са пословним аналитичарима, заинтересованим странама и стручњацима за обраду података.
  • ТДД невизуелно оријентисан
  • АМДД визуелно оријентисан
  • ТДД има ограничен опсег на софтверске радове
  • АМДД има широк опсег, укључујући и заинтересоване стране. Укључује рад на заједничком разумевању
  • Обоје подржавају еволутивни развој
 --------------------------------------------

Пример ТДД

Овде у овом примеру ћемо дефинисати лозинку за класу. За ову наставу покушаћемо да испунимо следеће услове.

Услов за прихватање лозинке:

  • Лозинка треба да има између 5 и 10 знакова.

Прво напишемо код који испуњава све горе наведене захтеве.

Сценариј 1 : Да бисмо покренули тест, креирамо класу ПассвордВалидатор ();

Трчићемо изнад класе ТестПассворд ();

Излаз је ПРОЛАЗЕН као што је приказано доле;

Излаз :

Сценариј 2 : Овде можемо видети у методи ТестПассвордЛенгтх () да нема потребе за креирањем инстанце класе ПассвордВалидатор. Инстанца значи стварање објекта класе који упућује на чланове (променљиве / методе) те класе.

Из кода ћемо уклонити класу ПассвордВалидатор пв = нев ПассвордВалидатор (). Методу исВалид () можемо позвати директно помоћу ПассвордВалидатор. ИсВалид ("Абц123") . (Погледајте слику испод)

Дакле, ми Рефактор (променимо код) као доле:

Сценариј 3 : Након рефакторирања излаза приказује се неуспели статус (погледајте слику доле), то је зато што смо уклонили инстанцу. Дакле, не постоји референца на нестатичну методу исВалид ().

Зато морамо да променимо ову методу додавањем речи "статиц" пре Боолеан-а као јавног статичког боолеан-а исВалид (Стринг лозинка). Рефакторирање класе ПассвордВалидатор () да би се уклонила горња грешка да би се прошао тест.

Излаз:

Након извршавања промена у класи ПассВалидатор (), ако покренемо тест, излаз ће бити ПРОЛАЗЕН као што је приказано доле.

Предности ТДД-а

  • Рано обавештење о грешкама.

    Програмери тестирају свој код, али у свету база података то се често састоји од ручних тестова или једнократних скрипти. Користећи ТДД, временом састављате скуп аутоматизованих тестова које ви и било који други програмер можете да поновите по својој вољи.

  • Боље дизајниран, чишћи и проширивији код.
    • Помаже у разумевању начина на који ће се код користити и како комуницира са другим модулима.
    • Резултат је боља одлука о дизајну и одрживији код.
    • ТДД омогућава писање мањег кода с једном одговорношћу, а не монолитним поступцима са вишеструким одговорностима. Ово олакшава разумевање кода.
    • ТДД такође приморава да напише само производни код да би прошао тестове на основу корисничких захтева.
  • Поверење Рефактору
    • Ако преправите код, могу постојати могућности прекида у коду. Дакле, имајући низ аутоматизованих тестова, можете поправити те паузе пре пуштања. Правилно упозорење ће бити дато ако се пронађу прекиди када се користе аутоматизовани тестови.
    • Коришћење ТДД-а требало би да резултира бржим, проширивим кодом са мање грешака који се могу ажурирати уз минималне ризике.
  • Добро за тимски рад

    У одсуству члана тима, други чланови тима могу лако да покупе и раде на шифри. Такође помаже у размени знања, чинећи тим у целини ефикаснијим.

  • Добро за програмере

    Иако програмери морају да потроше више времена на писање ТДД тест случајева, потребно је много мање времена за отклањање грешака и развој нових функција. Написаћете чистији, мање компликовани код.

Резиме:

  • ТДД је скраћеница од Тест-дривен девелопмент. То је процес модификације кода како би се прошао тест који је претходно дизајниран.
  • Више наглашава производни код, а не дизајн тест примера.
  • Развој вођен тестом је процес модификације кода како би се прошао тест који је претходно дизајниран.
  • У софтверском инжењерству је понекад познато и као „Тест Фирст Девелопмент“.
  • ТДД укључује рефакторирање кода, тј. Промену / додавање неке количине кода постојећем коду без утицаја на понашање кода.
  • ТДД када се користи, код постаје јаснији и једноставнији за разумевање.

Овај чланак је написао Канцхан Кулкарни