Шта је развој вођен тестом, приступи и предности

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

Практично тестни случајеви за сваку функцију се креирају и тестирају пре објављивања софтвера, а ако тест не успе, нови код се пише (или поново пише или закрпи) како би прошао тест и учинио код једноставним и без грешака.

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

Тест Дривен Девелопмент (ТДД) је настао као део веће парадигме дизајна софтвера познате као Ектреме Программинг (КСП), која је део Агиле методологије развоја софтвера.

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

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

Фазе ТДД приступа

Пре него што се напише било који нови код, програмер мора прво да направи неуспешан јединични тест. Затим, програмер – или пар, или мафија – креира довољно кода да задовољи тај захтев. Када тест прође, програмер може да рефакторише пројекат, правећи побољшања без промене понашања.

Док се ТДД фокусира на интеракције програмера на нивоу јединице, постоје и друге популарне методе, као што је развој вођен тестом прихватања (АТДД) или развој вођен понашањем (БДД), који се фокусирају на тестове које корисници могу разумети.

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

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

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

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

Очекивана корист:

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

Недостаци ТДД-а

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

Такође, многим програмерима недостају вештине да изолују и креирају чист код. Сви чланови тима морају креирати и одржавати јединичне тестове или ће они брзо постати застарели. А организација која гледа на ТДД ће морати да уложи време, да мало успори сада да би касније ишла брже.

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

Заједничке грешке:

• заборављајући да често покрећете тестове
• написати превише тестова одједном
• писати тестове који су превелики или груби
• писање претерано тривијалних тестова, као што је изостављање тврдњи
• писати тестове за тривијални код
• делимично усвајање: само неколико програмера у радној групи користи ТДД
• лоше одржавање тестног скупа, што најчешће доводи до скупа тестова са претерано дугим временом рада
• тест пакет је напуштен (тј. ретко се покреће или никада не покреће) – понекад због лошег одржавања, понекад због флуктуације тима

ТДД филозофија

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

Различите фазе укључене у развојни циклус вођен тестом су:

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

Ercole Palmeri