Խորհրդատուների և լավագույն փորձը Salesforce- ի ինտեգրացիաների փորձարկման համար

վաճառքի ինտեգրում

Salesforce- ի փորձարկումը կօգնի ձեզ հաստատել ձեր ընտրածը Salesforce ինտեգրումներ և ֆունկցիոնալ հնարավորություններ ձեռնարկության այլ ծրագրերի հետ: Լավ փորձարկումն ընդգրկում է Salesforce- ի բոլոր մոդուլները `հաշիվներից մինչև կապուղիներ, հնարավորություններից` հաշվետվություններ և արշավներից մինչև շփումներ: Ինչպես բոլոր թեստերի դեպքում, կա Salesforce փորձարկում կատարելու լավ (արդյունավետ և արդյունավետ) ձև և վատ միջոց: Այսպիսով, ո՞րն է Salesforce- ի փորձարկման լավ փորձը:

  • Օգտագործեք ճիշտ փորձարկման գործիքներ - Salesforce- ի փորձարկումը տեղի է ունենում զննարկչում կամ խավարման վրա հիմնված միջավայրում: Թե՛ վերջին զննարկիչները, թե՛ խավարումը ունեն վրիպազերծման հիանալի գործիքներ, և դրանք կարող եք համատեղել փորձարկման դասերի հետ ՝ շատ օգտակար արդյունքների համար: Այնուամենայնիվ, եթե ձեզ ավելին է պետք, ապա պետք է օգտագործվի Force.com- ի Apex Interactive Debugger (կամ պարզապես Apex): Նշեք, որ Salesforce Lightning- ը հատուկ փորձարկելու համար կարող եք նաև օգտագործել Salesforce Lightning Inspector, քրոմի ընդլայնում: Apex- ը ա Force.com հարթակի գույքային ծրագրավորման լեզու, որը շատ նման է Java- ի հետ: Այն օբյեկտի վրա կողմնորոշված, գործի վրա անզգայուն, խիստ տիպի ծրագրավորման լեզու է, որը հետևում է գանգուր փակագծերին և կետանշման շարահյուսությանը: Դուք կարող եք օգտագործել Apex- ը `ծրագրավորված գործառույթներն իրականացնելու համար Force.com- ի մեծամասնության գործընթացների ընթացքում, ներառյալ` հարմարեցված հղումներ և կոճակներ, թարմացումներ, ջնջումներ և գրառման տեղադրման իրադարձության կարգավարներ Visualforce էջի հատուկ կարգավորիչների կամ ժամանակացույցի միջոցով:
  • Օգտագործեք անվանումների պատշաճ պայմանագրեր - Քննության մեթոդների ճիշտ անվանակոչումը նախքան թեստեր գրելը սկսելը շատ կարևոր է: Թեստի մեթոդի անվանումը պետք է ունենա երեք մաս: Սրանք nameOfMethod են (ձեր կողմից փորձարկվող անհատական ​​մեթոդի անվանումն է, օրինակ ՝ ձգան փորձարկելիս ներդիր / թարմացնել / ջնջել / ջնջել, TestPath- ի մասին տեղեկատվություն, որը ճկուն է, օրինակ ՝ null contact, եթե ստուգում ես, որ կոնտակտը null է, և վավեր է փորձարկման ժամանակ դրական / բացասական ուղի:
  • Ապահովել 100% ծածկույթ - Չնայած Salesforce- ի ստանդարտ հրահանգն այն է, որ միավորի ստուգումը պետք է ունենա ձեր ծածկագրի 75% ծածկույթ (հանած թեստի դասեր, զանգեր System.debug և փորձարկման մեթոդներ), և դուք չեք կարողանա տեղակայել Apex ծածկագիր կամ փաթեթավորել AppExchange ծրագրերը, նշեք, որ սա պարզապես ստանդարտ է, և ձեր նպատակը պետք է լինի 100% ծածկույթ: Ստուգեք բոլոր դրական / բացասական դեպքերը, ինչպես նաև տվյալների առկայությունը և չլինելը: Կոդի ծածկույթի հետ կապված այլ կարևոր խորհուրդներ են.
    • Կոդի ծածկույթի համարները թարմացնելու համար դուք պետք է փորձարկումներ անցկացնեք, քանի որ Apex ծածկագիրը թարմացնելիս այս թվերը չեն թարմացվում, մինչև փորձերի կրկնությունը:
    • Եթե ​​վերջին փորձարկման ավարտից ի վեր կազմակերպությունում թարմացում է եղել, վտանգ կա, որ ծածկույթի ծածկագրի համարները սխալ կլինեն: Անցկացրեք թեստերը ճիշտ գնահատման համար:
    • Կոդի ծածկույթի տոկոսը չի պարունակում կառավարվող փաթեթների փորձարկումներից ծածկագրված ծածկագիր, բացառությամբ այն դեպքերի, երբ այդ փորձարկումները հրահրում են գործարկիչներին:
    • Cածկույթը կախված է ծածկագրերի տողերի ընդհանուր քանակից: Եթե ​​կոդեր եք ավելացնում կամ ջնջում, դուք կանդրադառնաք տոկոսի վրա:
  • Թեստային դեպքեր դասարաններում և կարգավարներում - Salesforce- ի զարգացման մեջ մշակողների մեծ մասը յուրաքանչյուր գործառույթի համար ստեղծում են առանձին դասեր և վերահսկիչ ֆայլեր: Դա արվում է կոդավորումը ավելի կազմակերպված, դյուրին, բազմակի օգտագործման և դյուրակիր դարձնելու համար: Պետք է, սակայն, նշել, որ չնայած դա ավելի հեշտ է, բայց ավելի արդյունավետ չէ: Դյուրակիրությանը կհասնեք, եթե փորձնական կոդը բուն դասի և հսկիչի կոդի մեջ է, քանի որ ավազարկղից արտադրություն տեղափոխվելիս բաց չեք թողնի որևէ փորձնական դաս:
  • Օգտագործեք System.assert () - Apex- ում, Համակարգ.հաստատել() օգտագործվում է պայմանները ստուգելու համար: Սա կարևոր ֆունկցիոնալություն է, քանի որ այն թույլ է տալիս պարզել, թե արդյոք որոշակի ֆունկցիա կատարվել է մեթոդով, ինչպես սպասվում է: Դուք պետք է օգտագործեք System.assertEquals () և System.assertNotEquals () կարևոր գործառույթների արանքում ոչ միայն օգնում է ձեզ պարզել, թե արդյոք կոդն իրականացվել է այնպես, ինչպես պետք է, այլ նաև ապահովել, որ ոչ մի սխալ տվյալ չի գրվել, եթե կոդը սխալ է գործում:
  • Համապարփակ թեստ - Թեստավորումը պետք է ներառի ամեն ինչ: Դուք պետք է կատարեք ֆունկցիոնալ փորձարկում, բեռի փորձարկում, անվտանգության փորձարկում և տեղակայման փորձարկում:
  • Միավորների թեստեր - Դուք պետք է ունենաք միավորի թեստեր `ստուգելու համար, որ անհատական ​​գրառումները տալիս են ճիշտ և սպասված արդյունք: Չնայած ամբողջ կոդն ընդգրկող հսկա թեստ օգտագործելը կարող է թվալ որպես լավ գաղափար, նշեք, որ ստացված արդյունքները ավելի դժվար է ապօրինել, իսկ ձախողումը `ավելի դժվար ընկալելի: Միավորի ստուգումը պետք է ներառի փորձարկվող գործառույթների մի փոքր ենթաբազմություն:
  • Թեստային զանգվածային դեպքեր - Լավ փորձարկման ծածկագիրը (ձգան, բացառություն կամ դաս) կարող է ներգրավվել մինչև մի քանի հարյուր գրառումների համար (200-ը Apex- ի համար): Դուք պետք է օգտվեք դրանից և ստուգեք ոչ միայն անհատական ​​գրառումները, այլ նաև սորուն դեպքերը:
  • Դրական թեստեր - Թեստ ՝ համոզվելու համար, թե արդյոք սպասված վարքը տեղի է ունենում բոլոր սպասվող փոխարկումների միջոցով: Թեստը պետք է ստուգի, որ օգտագործողը ճիշտ է լրացրել ձևաթուղթը, և որ նա չի անցել սահմանները:
  • Բացասական թեստեր - Ստուգեք բացասական դեպքերը ՝ սխալ հաղորդագրությունների ճիշտ արտադրությունը ապահովելու համար: Նման բացասական դեպքերի օրինակներն են `չկարողանալով նշել բացասական գումարներ և չկարողանալով ավելացնել ապագա ամսաթվերը: Բացասական թեստերը կարևոր են, քանի որ ճիշտ վարվելը, երբ ամեն ինչ գնում է դեպի հարավ, կարող է մեծ նշանակություն ունենալ:
  • Ավտոմատացնել թեստավորումը - Ավանդաբար, Salesforce- ի փորձարկումը ձեռնարկ էր: Պետք է հաշվի առնել ավտոմատացված փորձարկումը, քանի որ սա ավելի շատ առավելություններ է առաջարկում: Դրանք ներառում են.
    • Ձեռնարկի փորձարկումը ձեզ ենթակա է սխալների, քանի որ փորձարկումը կատարվում է ոչ թե ռոբոտների, այլ մարդկանց կողմից: Ռոբոտները գերազանցում են կրկնվող գործողությունները, մինչդեռ մարդիկ սխալներ են գործում ձանձրույթի, կենտրոնացվածության և կայունության նվազման և անկյունները կտրելու հակումների պատճառով:
    • Ձեռնարկի փորձարկումը կրկնվող է, բանաձևային և հոգնեցուցիչ: Թեստավորման թիմը ավելի լավ է, որ կատարի ավելի որոնողական աշխատանք:
  • Կատարել Code Code- ի յուրաքանչյուր մասնաճյուղ - Պայմանական տրամաբանություն օգտագործելիս (երբ դուք ներառել եք երրորդական օպերատորներ), ծածկագրի տրամաբանության յուրաքանչյուր ճյուղ պետք է կատարվի:
  • Օգտագործել անվավեր և վավեր մուտքեր մեթոդների զանգերի համար - Դեպի մեթոդներ կանչերը պետք է իրականացվեն ինչպես անվավեր, այնպես էլ վավեր մուտքագրման միջոցով:
  • Ամբողջական թեստեր - Համոզվեք, որ թեստերը հաջողությամբ կավարտվեն. Դրանք չպետք է բացառությունների միջով անցնեն, եթե սխալներ չեն սպասվում: Կարգավորեք բռնված բոլոր բացառությունները. Նրանց բռնելը բավականաչափ լավ չէ:
  • Օգտագործեք Պատվիրել ըստ հիմնաբառերի - Ապահովելու համար, որ ձեր գրառումները վերադարձվեն ըստ ձեր ակնկալած կարգի, օգտագործեք ՊԱՏՎԵՐ ՈՐՊԵՍ հիմնաբառեր
  • Մի՛ ենթադրեք, որ գրառման ID- ները հաջորդաբար դասավորված են - Խուսափեք ռեկորդային նույնականացման ID- ները դասավորվածության ենթադրելու ընդհանուր սխալից: Նույնականացման վկայականները աճման կարգով չեն, եթե միևնույն խնդրանքով բազմաթիվ գրառումներ չեք տեղադրել:
  • Callանգահարեք Test.startTest () և Test.stopTest () - Apex միավորի թեստ անցկացնելիս կստանաք ավելի քան 75% ծածկույթի ծածկույթ, որը պարտադիր է Salesforce- ում: Հաստատումներից առաջ պետք է զանգահարեք stopTest ՝ ստիպելու ասինխրոն կոդերը, որոնք դեռ կարող են ավարտվել: Գործարկել թարմ հարցումներ վերջնական արդյունքների համար, քանի որ այլ ծածկագիրը կարող է փոխել տվյալները: UsingTest.startTest () - ի և Test.stopTest- ի () օգտագործումը ապահովում է ձեզ ստուգել փորձնական փորձարկումն իր կառավարչի սահմաններում: Այս կերպ, ձեր օգտագործած կարգաբերման ծածկագիրը չի խանգարի և ձեզ կեղծ բացասական կողմեր ​​կամ դրական կողմեր ​​չի տալիս կառավարչի սահմանների շուրջ: Test.stopTest- ը () նաև ապահովում է, որ @future զանգերը կավարտվեն փորձարկման համար:
  • Ընթեռնելիություն - Ընթերցանությունը շատ կարևոր է միավորների թեստերում: Թեստի անունները պետք է ներառեն ձեռնարկվող հատուկ գործողությունները և ակնկալվող արդյունքը: Մեթոդը պետք է լինի նկարագրական և կարճ: Մեթոդը պետք է լինի այնպիսին, որ այն հնարավոր լինի բազմակի օգտագործել տարբեր թեստերի միջոցով:
  • Կառուցեք թեստային տվյալների մեծ հավաքածու `նախքան startTest- ը - Քանի որ ձեր թեստերը կաշխատեն ավազատուփի և արտադրության տարբեր միջավայրերում, նախքան startTest- ը զանգահարելը կառուցեք մեծ փորձարկման տվյալների հավաքածու ՝ ապահովելու համար, որ թեստը կատարման լրիվ սահմաններ ունի: Ըստ նախնականի, Salesforce Github իրականացնում է արտադրության տվյալներից մեկուսացված թեստեր: Երբ Ձեզ անհրաժեշտ են համակարգի տվյալներ, ինչպիսին է պրոֆիլը, հարցում կատարեք ՝ այդ հատուկ միջավայրի համար ճիշտը ստանալու համար:
  • Ստեղծեք ձեր սեփական փորձարկման տվյալները - Քննության տվյալները, որոնք դուք օգտագործում եք, պետք է գեներացվեն թեստում: Դուք կարող եք առաջացնել այս տվյալները ՝ օգտագործելով @testSetup անոտացիան և TestUtils դասը ՝ ոչ միայն ապահովելու համար, որ դուք ունեք ճիշտ տվյալներ, այլ նաև ապահովելու, որ բոլոր թեստերը գործարկվեն մշակողի ավազարկղում, առանց տվյալների պահանջի:
  • Խուսափեք AKA անվավեր գործողություններից ՝ Շատ փորձարկողներ օգտագործում են առանց op-AKA- ի զրոյական գործողություններ: Սրանք անօգուտ ծածկագրեր են, որոնք ոչինչ չեն ձեռնարկում: Քանի որ դրանք արդեն գտնվում են ձեր կոդի բազայում, դրանք կավելանան ձեր ծածկույթի տոկոսին:
  • Testուգահեռ թեստի կատարում - Երբ սկսում եք փորձարկումները Salesforce- ի օգտագործողի միջերեսից կամ Developer Console- ից, թեստերը զուգահեռ կընթանան: Սա կարևոր առանձնահատկություն է, քանի որ այն արագացնում է փորձարկման ժամանակը: Այնուամենայնիվ, պետք է նկատեք, որ դա կարող է հանգեցնել տվյալների վիճարկման հետևանքների, և եթե կասկածում եք, որ դա կարող է տեղի ունենալ, անջատեք զուգահեռ կատարումը: Տվյալների վիճաբանության հետ կապված խնդիրների ամենատարածված պատճառները, որոնք հաճախ հանգեցնում են UNABLE_TO_LOCK_ROW սխալների ՝
    • Երբ թեստերը կոչված են միաժամանակ թարմացնել նույն գրառումները: Նույն գրառումների թարմացումը սովորաբար տեղի է ունենում, երբ թեստերը չեն ստեղծում իրենց սեփական տվյալները:
    • Երբ զուգահեռ ընթացող թեստերում փակուղի է առաջանում, և նրանք փորձում են ստեղծել գրառումներ, որոնք ունեն համապատասխան ինդեքսի դաշտի արժեքներ: Փակուղի կառաջանա, երբ 2 գործարկման թեստերը հերթագրելու համար հերթագրեն տվյալները (դա տեղի է ունենում, երբ 2 թեստ մուտքագրում է գրառումներ, որոնք տարբեր պատվերներում ունեն նույն եզակի ինդեքսի դաշտի արժեքները):
    • Testուգահեռ թեստի կատարումն անջատելու համար անցեք Setup, մուտքագրեք Apex Test, անցեք Apex Test Execution Options ընտրանքներ, ընտրեք Disable Paralelel Apex Testing, կտտացրեք OK:

Անջատեք գագաթնակետին զուգահեռ թեստավորումը

Աշխատանքի համար վարձեք մասնագետի, քանի որ նա կունենա փորձ և վերապատրաստում, որոնք անհրաժեշտ են լավ փորձարկում կատարելու համար, ինչը ձեզ նույնպես հանգիստ է տալիս: Մասնագետ վարձելը թույլ է տալիս կենտրոնանալ ձեր հիմնական բիզնեսի վրա: Դա նաև ձեզ գումար է խնայում, քանի որ աշխատանքի համար ձեզ հարկավոր չէ ներքին թիմ:

Այս կայքը օգտագործում է Akismet- ը սպամի նվազեցման համար: Իմացեք, թե ինչպես է ձեր տվյալները մշակվում.