Փոփոխությունն անխուսափելի է, հետևաբար շատ հազվադեպ է պատահում, որ դուք գրեք ինչ-որ կոդ և այլևս չդիպչեք դրան: Քանի որ պահանջները փոխվում են, ձեր ծածկագիրը նույնպես կփոխվի:

Ձեր ծրագրաշարի փորձարկումը հիանալի միջոց է իմանալու, թե արդյոք ձեր կոդը գործում է այնպես, ինչպես սպասվում էր, թե ոչ: Թեստերը կան՝ համոզվելու համար, որ դուք կհասկանաք ապագա փոփոխությունների չնախատեսված արդյունքները, մինչ դուք շարունակեք զարգացման գործընթացը: Բայց թեստերն էլ մարդիկ են գրում, ու մարդիկ սխալվում են։ Նույնիսկ եթե դուք գրում եք մեծ քանակությամբ թեստեր, որոնք, թվում է, ստուգում են յուրաքանչյուր դեպք, անիրատեսական է հավատալ, որ դուք իրականումստուգել եք յուրաքանչյուր դեպք:

Ծածկույթը չափիչ է, որը լայնորեն օգտագործվում է որոշելու, թե ձեր կոդի քանի տոկոսն է փորձարկվել փորձնական փաթեթի կողմից: Բարձր ծածկույթը մեկնաբանվում է, քանի որ քիչ հավանական է, որ ձեր կոդի մեջ ինչ-որ տեղ չհայտնաբերված վրիպակ լինի: Թեև ծածկույթը կարևոր է, այն ձեզ ասում է միայն ձեր թեստերի կողմից կատարված կոդի տոկոսը, որը սովորաբար բավարար չէ թեստի որակը որոշելու համար:

Մուտացիայի թեստավորումըսպիտակ տուփի թեստավորման տեսակ է, որը կարող է բավականին լավ պատկերացում տալ ձեր թեստերի որակի մասին: Մուտացիաների թեստավորման ամբողջ իմաստը կայանում է նրանում, որ ցույց տան, թե արդյոք ձեր թեստերն ի վիճակի են հայտնաբերելու նուրբ սխալները, որոնք կարող են ներկայացվել ապագայում: Մուտացիաների փորձարկման շրջանակները վերցնում են ձեր սկզբնական կոդը և ներմուծում են որոշ փոփոխություններ, որոնք կոչվում ենմուտացիաներ: Միավորի թեստերն իրականացվում են ինչպես սկզբնական աղբյուրի, այնպես էլ մուտացիայի ենթարկված տարբերակի դեմ, և արդյունքները համեմատվում են:

Բոլոր թեստերն անցնում են մուտացիայից հետո → Մուտացիան պահպանվել է (Վա՜յ։

Մուտացիայի օպերատորներ

Յուրաքանչյուր մուտացիայի համար մուտացիայի օպերատորը կիրառվում է կոդի հատվածի վրա: Մուտացիայի օպերատորը մի փոքր փոփոխություն է կատարում կոդի վրա՝ դրա վարքագիծը փոխելու համար: Ահա մի քանի ընդհանուր մուտացիայի օպերատորներ.

  • Բուլյան արտահայտությունը փոխարինիր ճշմարիտ կամ կեղծով
  • Վերադարձի արժեքը փոխարինեք հաստատուն արտահայտությամբ
  • Չեղարկել պայմանական ստուգումը (փոխարկել ավելի քիչ, քան ավելի մեծ)
  • Փոխարինեք թվաբանական օպերատորները ուրիշներով:

Մուտացիաները սովորաբար ներմուծվում են կոդի համար մեկ առ մեկ, այլ ոչ թե դրանցից մի քանի անգամ միաժամանակ: Սրա պատճառն այն է, որ բազմաթիվ մուտացիաները կարող են ծածկագիրը ամբողջովին անտեղի դարձնել: Նաև հնարավոր է, որ մեկ մուտացիան կարող է պատահաբար սպանել մեկ այլ մուտացիա՝ հանգեցնելով թեստեր անցնելուն, երբ դրանք չպետք է անեին:

Մուտացիաների փորձարկման շրջանակներ

Քանի որ դա ձանձրալի կլիներ դա անել ձեռքով, մենք ունենք մուտացիաները ավտոմատ կերպով ներկառուցելու շրջանակներ և մեր բոլոր թեստերը մեզ համար գործարկելու համար: Նրանք նաև տրամադրում են արդյունքների մանրամասն վերլուծություն, ներառյալ մուտացիաների քանակը, սպանված մուտացիաների տոկոսը, կոդի որ մասերին են ներկայացվել մուտացիաները և այլն:

Գործընթացը օրինակով ցուցադրելու համար ես կօգտագործեմ PITest Java-ում: Դա հեշտ օգտագործվող բաց կոդով գրադարան է, որը մշակվել է Հենրի Քոուլսի կողմից: Ահա մի քանի շրջանակներ, որոնք կարող եք օգտագործել տարբեր ծրագրավորման լեզուներում.

Մուտացիայի թեստավորում PITest-ով

PITest-ը կարող է օգտագործվել որպես պարզ հրամանի տող գործիք, բայց այն նաև մեծ աջակցություն ունի կախվածության շրջանակների համար, ինչպիսիք են Gradle-ը և Maven-ը: Ես կօգտագործեմ այն ​​Maven նախագծում, բայց դուք կարող եք նաև հետևել PITest-ի պաշտոնական փաստաթղթերին` տեսնելու, թե ինչպես է այն աշխատում այլ կախվածության կառավարիչների հետ:

Ձեռք բերեք PITest Plugin-ը և JUnit Dependency-ը:

MVNRepository-ն հիանալի վայր է արտաքին գրադարանների կախվածությունները գտնելու համար: Այն պարունակում է կախվածություն այլ կախվածության կառավարիչների համար, ինչպես նաև, ոչ միայն Maven-ի համար: Եկեք ստանանք PITest 1.5.0 հավելվածը և JUnit-ը:

Քայլ 1 — Գրեք որոշ կոդ և միավորի թեստեր դրա համար

Ես գրել եմ մի պարզ կոդ, որը պարզապես ստուգում է՝ արդյոք լարման մակարդակը վտանգավոր է, թե ոչ: Վտանգավոր լարման մակարդակները կարող են տարբեր լինել՝ կախված կիրառման տեսակից, ուստի այս դաշտը կազմաձևված է VoltageLevelAnalyzer-ի կոնստրուկտորի միջոցով:

Հիմա եկեք գրենք մի պարզ թեստային դեպք, որը ստուգում է, թե արդյոք is Dangerousիրականում վերադարձնում է true, երբ տրված լարման արժեքը ավելի բարձր է, քան ստորին սահմանը:

Քայլ 2 — Փորձարկեք թեստերը PITest-ով

Այժմ, երբ մենք ունենք փորձնական դեպք, եկեք օգտագործենք PITest-ի mvn հավելվածը՝ մուտացիաների ծածկույթ ստեղծելու համար.

mvn org.pitest:pitest-maven:mutationԾածկույթ

Այս հրամանը կձախողվի, եթե ձեր որոշ թեստեր արդեն ձախողվում են մուտացիաներից առաջ, եթե ոչ, այն կստեղծի մանրամասն հաշվետվություն html-ի տեսքով: Հաշվետվությունները ստեղծվում են հետևյալ կերպ.

./target/pit-reports/timestamp
./target/pit-reports/timestamp/package name/

Եկեք նայենք VoltageLevelAnalyzer.java.html-ին packagenameթղթապանակում:

Այո՛ Կարծես թե 4 մուտացիա է ներդրվել մեր կոդի մեջ, և մեր թեստը կարողացավ սպանել դրանցից միայն մեկը: Ինչպես տեսնում եք, զեկույցը ցույց է տալիս, թե որ տեսակի մուտացիայի օպերատորը որ գծի վրա է կիրառվել և գոյատևել է, թե ոչ: Եկեք անցնենք յուրաքանչյուր մուտացիայի վրա.

  • Մուտացիա 1. getDangerousVoltageLowerLimit-ի վերադարձի արժեքը փոխարինվեց 0-ով, բայց քանի որ մենք չենք փորձարկել այս մեթոդը, այն ծածկույթ չուներ:
  • Մուտացիա 2 — Վտանգավոր մեթոդի վերադարձի արժեքը փոխարինվել է true-ով: Քանի որ մենք փորձարկեցինք միայն լարման սահմանաչափից բարձր արժեքով, այս մուտացիան պահպանվեց:
  • Մուտացիա 3 — isDangerous մեթոդի ›= օպերատորը փոխվել է (օպերատորի հավասար մասը հեռացվել է): Այս մուտացիան պահպանվեց, քանի որ մենք չգրեցինք թեստ՝ ստուգելու եզրային գործը, որտեղ լարման մակարդակը հավասար է ստորին սահմանին:
  • Մուտացիա 4 — ›= օպերատորը ժխտվել է (փոխակերպվել է ‹=-ի): Մեզ հաջողվեց սպանել այս մուտացիան, քանի որ մեր մեկ թեստն այն ներառում է:

Եկեք գրենք ևս մի քանի թեստեր այս մուտացիաների դեմ պայքարելու համար:

Կրկին գործարկելով մուտացիաների վերլուծությունը, մենք կարող ենք տեսնել, որ բոլոր մուտացիաներն այժմ սպանվել են.

Մուտացիայի փորձարկման թերությունները

Թերությունների մեծ մասը հատուկ է ավելի մեծ նախագծերին: Եթե ​​սկզբնական ծրագիրը բավականին մեծ է, ապա գեներացված մուտանտների թիվը չափազանց մեծ կլինի: Այս մուտանտների ստեղծման համար կարող է երկար ժամանակ պահանջվել՝ մուտացիաների փորձարկումն իրականացնելու համար, և դրա ավարտից հետո բոլոր մուտանտների սպանությունը կարող է անհնարին լինել, հատկապես, եթե դուք հարմարեցնում եք այս մեթոդը արդեն մշակված կոդային բազային:

Եզրակացություն

Դուք կարող եք մտածել մուտացիայի փորձարկման մասին որպես անվտանգության միջոցի լրացուցիչ շերտ: Ձեր գծի ծածկույթի վերևում, մուտացիաների ծածկույթը կարող է օգտագործվել ձեր թեստերի որակը բարելավելու համար: Այն ձեզ ուղեցույց է տալիս ձեր միավորի թեստերը ձևավորելու համար:

Արդյո՞ք դա նշանակում է, որ եթե դուք սպանում եք բոլոր մուտացիաները, ձեր ծրագրաշարը զերծ է սխալներից: Իհարկե ոչ: Մուտացիայի փորձարկումը կարող է օգնել ձեզ հայտնաբերել որոշ վրիպակներ՝ նախքան դրանք արտադրություն մտցնելը, բայց դա չի երաշխավորում վրիպազերծ համակարգ: Սա պարզապես միջոց է չափելու, թե որքան լավ է ձեր թեստային փաթեթը անոմալիաներ հայտնաբերելու հարցում, և դա անում է դա՝ ենթադրելով, որ ձեր կոդը տրամաբանորեն ճիշտ է: Անկախ նրանից, ամենակարևորը այս տեխնոլոգիաներից հնարավորինս շատ ավելացնելն է ձեր զինանոցում, որպեսզի նվազագույնի հասցնեք հնարավոր գլխացավերը: Կատարյալ ծրագրակազմ գրելը միֆ է: Կատարելությունը անընդհատ շարժվող նպատակ է, և այն ամենը, ինչ մենք կարող ենք անել, դա հետապնդելն է՝ բարելավելով մեր կոդը և հնարավորինս մեղմացնելով հնարավոր կողմնակի ազդեցությունները:

Հղումներ:





«Մուտացիայի թեստավորում
Մուտացիայի թեստը (կամ մուտացիայի վերլուծությունը կամ ծրագրի մուտացիան) օգտագործվում է նոր ծրագրային թեստեր մշակելու և…en.wikipedia.org-ը գնահատելու համար: