Што такое Test Driven Development, падыходы і перавагі

Тэставая распрацоўка (TDD) - гэта падыход да распрацоўкі праграмнага забеспячэння, пры якім распрацоўваюцца тэставыя прыклады, каб вызначыць і праверыць, што будзе рабіць код.

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

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

Тэставая распрацоўка (TDD) узнікла як частка больш шырокай парадыгмы распрацоўкі праграмнага забеспячэння, вядомай як экстрэмальнае праграмаванне (XP), якая з'яўляецца часткай метадалогіі распрацоўкі праграмнага забеспячэння Agile.

Простая канцэпцыя TDD заключаецца ў напісанні і выпраўленні няўдалых тэстаў перад напісаннем новага кода (да распрацоўкі). Гэта дапамагае пазбегнуць дубліравання кода, паколькі мы пішам невялікую колькасць кода за раз, каб прайсці тэсты. (Тэсты - гэта не што іншае, як умовы патрабаванняў, якія мы павінны праверыць, каб задаволіць іх).

Тэставая распрацоўка - гэта працэс распрацоўкі і запуску аўтаматызаваных тэстаў перад фактычнай распрацоўкай прыкладання. Такім чынам, TDD таксама часам называюць Test First Development.

Фазы падыходу TDD

Перш чым напісаць новы код, праграміст павінен стварыць няўдалы модульны тэст. Затым праграміст - або пара, або натоўп - стварае дастаткова кода, каб задаволіць гэтае патрабаванне. Пасля таго, як тэст пройдзены, праграміст можа рэарганізаваць праект, уносячы паляпшэнні без змены паводзін.

У той час як TDD засяроджваецца на ўзаемадзеянні праграмістаў на ўзроўні адзінак, ёсць і іншыя папулярныя метады, такія як распрацоўка, арыентаваная на прыёмачныя тэсты (ATDD) або распрацоўка, арыентаваная на паводзіны (BDD), якія сканцэнтраваны на тэстах, зразумелых кліентам.

Гэтыя метады прадугледжваюць стварэнне рэальных прыкладаў у выглядзе сумесных тэстаў паміж інжынерным персаналам і кліентам перад кадзіраваннем, а затым запуск тэстаў пасля кадавання, каб прадэманстраваць, што код рэалізаваны. Наяўнасць тэстаў, вядомых загадзя, паляпшае якасць першага разу. ATDD і BDD патрабуюць ад распрацоўшчыкаў, тэсціроўшчыкаў і дзелавых колаў працаваць разам, каб уявіць і абмеркаваць праграмнае забеспячэнне і яго наступствы перад стварэннем кода.

Перавагі TDD

Тэставая распрацоўка можа ствараць высакаякасныя прыкладанні за меншы час, чым гэта магчыма з дапамогай старых метадаў. Паспяховае ўкараненне TDD патрабуе ад распрацоўшчыкаў і тэсціроўшчыкаў дакладнага прадбачэння таго, як прыкладанне і яго функцыянальнасць будуць выкарыстоўвацца ў рэальным свеце.

TDD стварае набор рэгрэсіўных тэстаў у якасці пабочнага эфекту, які можа звесці да мінімуму ручное тэсціраванне чалавекам, выяўляючы праблемы раней, што прыводзіць да больш хуткіх рашэнняў. Метадычная прырода TDD забяспечвае значна большы ахоп і якасць першага разу, чым класічныя паэтапныя цыклы кода > тэст > выпраўленне > паўторнае тэставанне. Паколькі тэсціраванне праводзіцца на ранняй стадыі цыкла праектавання, час і грошы, затрачаныя на наступную адладку, зведзены да мінімуму.

Чаканыя перавагі:

• значнае зніжэнне ўзроўню дэфектаў за кошт умеранага павелічэння першапачатковых намаганняў па распрацоўцы
• накладныя выдаткі з лішкам кампенсуюцца скарачэннем намаганняў на апошніх стадыях праектаў
• TDD прыводзіць да лепшай якасці дызайну ў кодзе і, у больш агульным плане, да больш высокай ступені «ўнутранай» або тэхнічнай якасці, напрыклад, за кошт паляпшэння паказчыкаў згуртаванасці і сувязі

Недахопы TDD

TDD патрабуе значных навыкаў, каб дасягнуць поспеху, асабліва на ўзроўні падраздзялення. Многія састарэлыя сістэмы проста не створаны з улікам модульнага тэсціравання, што робіць немагчымым ізаляцыю кампанентаў для тэставання.

Акрамя таго, многім праграмістам не хапае навыкаў ізаляцыі і стварэння чыстага кода. Усе члены каманды павінны ствараць і падтрымліваць модульныя тэсты, інакш яны хутка састарэюць. І арганізацыі, якая шукае TDD, прыйдзецца ўкласці час, крыху запаволіць зараз, каб потым паскорыць.

Нарэшце, як і ў выпадку з любым метадам, канчатковыя вынікі TDD настолькі добрыя, наколькі добрыя тэсты, якія былі выкарыстаны, наколькі дакладна яны былі выкананы і наколькі яны імітуюць умовы, з якімі сутыкаюцца карыстальнікі канчатковага прадукту.

Частыя памылкі:

• часта забываючы запускаць тэсты
• пісаць занадта шмат тэстаў адначасова
• пісаць тэсты, якія занадта вялікія або грубыя
• напісанне празмерна трывіяльных тэстаў, такіх як пропуск сцвярджэнняў
• пісаць тэсты для трывіяльнага кода
• частковае прыняцце: толькі некалькі распрацоўшчыкаў у рабочай групе выкарыстоўваюць TDD
• дрэннае абслугоўванне набору тэстаў, што часцей за ўсё прыводзіць да набору тэстаў з занадта доўгім часам выканання
• набор тэстаў закінуты (г.зн. рэдка ці ніколі не запускаецца) - часам з-за дрэннага абслугоўвання, часам з-за змены каманды

Філасофія TDD

TDD дазваляе праграмісту рабіць маленькія крокі пры напісанні праграмнага забеспячэння. Тэст пішацца перад тэставаннем функцыянальнасці і гарантуе, што прыкладанне прыдатна для тэставання. Тэставанне невялікай колькасці кода праводзіцца для выяўлення памылак, якія ўзнікаюць у тэсціруемым кодзе. Затым функцыянал рэалізуецца. Гэта называецца "чырвона-зялёным рэфактарам", дзе чырвоны азначае правал, а зялёны - пропуск. Затым гэтыя крокі паўтараюцца. Першая мэта праграміста - засяродзіцца на пастаўленай задачы і пераадолець яе.

Розныя этапы цыклу распрацоўкі на аснове тэставання:

• Дадаць тэст: кожная новая функцыя ў TDD пачынаецца з тэсту, які павінен быць няўдалым, бо ён уводзіцца на месца перад рэалізаваннем любой функцыі. Абавязковай умовай для напісання тэсту перад укараненнем функцыі з'яўляецца дакладнае разуменне патрабаванняў распрацоўшчыкам. Гэта дасягаецца з дапамогай гісторый карыстальнікаў і варыянтаў выкарыстання. Такім чынам, распрацоўшчык разумее патрабаванне да напісання праграмнага кода.
• Запусціце ўсе тэсты і праверце, ці не атрымаецца новы код: гэта гарантуе, што тэставая сістэма працуе карэктна і што новы тэст не будзе правалены без новага кода. Гэты крок таксама правярае тэст і выключае магчымасць таго, што новы тэст заўсёды будзе праходзіць.
• Напісаць код: наступным крокам з'яўляецца напісанне кода, які ачышчае тэст. Новы код не з'яўляецца ідэальным, але пазней быў зменены ў адпаведнасці з патрабаваннямі. Ён прызначаны проста для тэставання і не мае іншых функцый.
• Запусціце аўтаматызаваныя тэсты: калі кожны выраблены тэст лёгка праходзіць тэст, гэта азначае, што код адпавядае ўсім патрабаваным спецыфікацыям. Затым можна пачынаць заключную фазу цыклу.
• Рэфактарынгу кода: гэта падобна на выдаленне дублявання. Рэфактарынгі не парушаюць існуючыя функцыі і дапамагаюць выдаліць дубліраванне паміж працоўным і тэставым кодам. Цяпер код ачышчаны па меры неабходнасці.
• Паўтарыць: цыкл паўтараецца, як і ў папярэдніх выпадках, з новым тэстам. Істотнае патрабаванне заключаецца ў тым, каб памер кроку быў невялікім, з прыкладна 1-10 зменамі паміж кожным тэставым запускам. Калі новы код не праходзіць новы тэст, праграміст павінен зрабіць больш адладкі. Бесперапынная інтэграцыя забяспечвае зварачальныя кантрольныя кропкі.

Ercole Palmeri