Ինչ է թեստի վրա հիմնված զարգացումը, մոտեցումներն ու առավելությունները

Test Driven Development (TDD) ծրագրային ապահովման մշակման մոտեցում է, որտեղ փորձարկման դեպքերը մշակվում են՝ հստակեցնելու և վավերացնելու համար, թե ինչ է անելու կոդը:

Գործնականորեն փորձարկման դեպքեր յուրաքանչյուր հատկանիշի համար ստեղծվում և փորձարկվում են նախքան ծրագրաշարի թողարկումը, և եթե թեստը ձախողվում է, նոր կոդ է գրվում (կամ վերագրվում կամ կարկատվում է)՝ թեստն անցնելու և կոդը պարզ և առանց վրիպակների:

Test Driven Development (TDD) սկսվում է հավելվածի յուրաքանչյուր փոքրիկ հատկանիշի համար թեստերի նախագծմամբ և մշակմամբ: TDD շրջանակը ծրագրավորողներին հրահանգում է նոր կոդ գրել միայն այն դեպքում, եթե ավտոմատացված թեստը ձախողվի: Այս մոտեցումը խուսափում է կոդի կրկնությունից: Ամբողջական TDD մոդուլը փորձարկման վրա հիմնված մշակում է:

Test Driven Development (TDD) առաջացել է որպես ծրագրային ապահովման նախագծման ավելի մեծ պարադիգմի մաս, որը հայտնի է որպես Extreme Programming (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-ում յուրաքանչյուր նոր հատկություն սկսվում է մի թեստով, որը պետք է ձախողվի, քանի որ այն տեղադրվում է նախքան որևէ հատկանիշի ներդրումը: Գործառույթի ներդրումից առաջ թեստ գրելու նախապայման է մշակողի կողմից պահանջի հստակ ըմբռնումը: Սա ձեռք է բերվում օգտվողների պատմությունների և օգտագործման դեպքերի միջոցով: Այսպիսով, մշակողը հասկանում է պահանջը նախքան ծրագրի կոդը գրելը:
• Գործարկեք բոլոր թեստերը և ստուգեք, թե արդյոք նոր կոդը ձախողվում է. սա երաշխավորում է, որ թեստային ամրագոտիը ճիշտ է աշխատում, և որ նոր թեստը չի ձախողվում առանց որևէ նոր կոդի: Այս քայլը նաև ստուգում է թեստը և վերացնում է նոր թեստը միշտ անցնելու հնարավորությունը:
• Գրել կոդը. Հաջորդ քայլը, որը հաջորդում է, գրելն է, որը մաքրում է թեստը: Նոր կոդը կատարյալ չէ, բայց հետագայում փոփոխվել է ըստ պահանջների: Այն նախատեսված է պարզապես փորձարկման համար և չունի այլ հնարավորություններ:
• Գործարկել ավտոմատացված թեստեր. Եթե արտադրված յուրաքանչյուր փորձնական դեպք հեշտությամբ անցնի թեստը, դա նշանակում է, որ կոդը համապատասխանում է բոլոր պահանջվող բնութագրերին: Այնուհետև կարելի է սկսել ցիկլի վերջնական փուլը:
• Refactoring code. Սա նման է կրկնօրինակումը հեռացնելուն: Refactoring-ը չի խախտում գոյություն ունեցող որևէ գործառույթ և օգնում է հեռացնել կրկնօրինակումը արտադրության և փորձարկման կոդի միջև: Այժմ կոդը մաքրվում է ըստ պահանջի:
• Կրկնել. ցիկլը կրկնվում է ինչպես նախորդ դեպքերում՝ նոր թեստով: Էական պահանջն այն է, որ քայլի չափը փոքր լինի՝ յուրաքանչյուր փորձարկման միջև մոտ 1-10 փոփոխություններով: Եթե ​​նոր կոդը ձախողվի նոր թեստում, ծրագրավորողը պետք է ավելի շատ վրիպազերծում կատարի: Շարունակական ինտեգրումն ապահովում է շրջելի անցակետեր:

Ercole Palmeri