Nõuanded ja parimad tavad Salesforce'i integratsioonide testimiseks

müügijõu integreerimine

Salesforce'i testimine aitab teil kohandatud valideerida Salesforce'i integreerimised ja funktsioonid teiste ettevõtte rakendustega. Hea test hõlmab kõiki Salesforce'i mooduleid kontodelt müügivihjeteni, võimalustest aruanneteni ja kampaaniatest kontaktideni. Nagu kõigi testide puhul, on ka Salesforce'i testi tegemiseks hea (tõhus ja tõhus) viis ja halb viis. Niisiis, mida testib Salesforce head tava?

  • Kasutage õigeid testimistööriistu - Salesforce'i testimine toimub brauseris või varjutuspõhises keskkonnas. Nii viimastes brauserites kui ka varjutuses on suurepärased silumisvahendid ja saate väga kasulike tulemuste saamiseks need kombineerida testiklassidega. Kui vajate aga rohkem, tuleks kasutada Force.comi väljaannet The Apex Interactive Debugger (või lihtsalt Apex). Pange tähele, et saate Salesforce Lightning'i testimiseks kasutada ka kroomitud laiendust Salesforce Lightning Inspector. Apex on a Force.com platvormi patenteeritud programmeerimiskeel, millel on Java-ga palju sarnasusi. See on objektile orienteeritud, suurtähteta tundlik, tugevalt tüüpiline programmeerimiskeel, mis järgib lokkisulgude ja punktmärkide süntaksit. Apexi abil saate programmeeritud funktsioone täita enamiku Force.com-i protsesside ajal, sealhulgas kohandatud linkide ja nuppude, värskenduste, kustutuste ja kirjete sisestamise sündmuste käitlejad Visualforce'i lehe kohandatud kontrollerite või ajastamise kaudu.
  • Kasutage õigeid nimetamiskonventsioone - Enne testide kirjutamise alustamist on katsemeetodite õige nimetamine väga oluline. Katsemeetodi nimel peaks olema kolm osa. Need on nameOfMethod (testitava üksiku meetodi nimi, näiteks käiviti testimisel sisestamine / värskendamine / kustutamine / tühistamine, teave TestPathi kohta, mis on paindlik, näiteks nullkontakt, kui testite, et kontakt on null, ja testimisel kehtiv positiivne / negatiivne tee.
  • Tagage 100% katvus - Kuigi standardne Salesforce'i direktiiv on see, et üksustesti peaks katma 75% teie koodist (miinus testiklassid, kõned System.debugile ja testimeetodid) ning te ei saa Apexi koodi ega AppExchange'i pakette juurutada, peaksite siiski pange tähele, et see on lihtsalt standard ja teie eesmärk peaks olema 100% katvus. Testige kõiki positiivseid / negatiivseid juhtumeid ja andmeid, mis on olemas ja mida pole. Muud olulised näpunäited koodikatvuse osas on:
    • Koodide katvusnumbrite värskendamiseks peaksite käivitama testid, kuna Apexi koodi värskendamisel neid numbreid ei värskendata, kuni testid on uuesti tehtud.
    • Kui organisatsioonis on pärast viimast testisõitu värskendatud, on oht, et koodide katvuse numbrid on valed. Õige hinnangu saamiseks tehke testid uuesti.
    • Koodide katvuse protsent ei sisalda hallatud pakettide testide katvust, ainus erand on see, kui need testid põhjustavad päästikute käivitamise.
    • Katvus sõltub koodiridade koguarvust. Kui lisate või kustutate koodiridu, mõjutab see protsenti.
  • Katsekohad klassides ja kontrollerid - Salesforce'i arenduses loob enamik arendajaid iga funktsiooni jaoks eraldi klassid ja kontrollerifailid. Seda tehakse selleks, et muuta kodeerimine korrastatumaks, lihtsamaks, korduvkasutatavamaks ja kaasaskantavaks. Peaksite siiski arvestama, et kuigi see on lihtsam, ei ole see siiski tõhusam. Teisaldatavuse saavutate, kui testkood on algklassi ja kontrolleri kood ise, kuna liivakastist tootmisse üleminekul ei jää ükski testklassi kasutamata.
  • Kasutage System.assert () - Apexis System.assert() kasutatakse tingimuste kontrollimiseks. See on oluline funktsioon, kuna see võimaldab teil kindlaks teha, kas konkreetne funktsioon on meetodi abil oodatud viisil täidetud. Kriitiliste funktsioonide vahel peaksite kasutama System.assertEquals () ja System.assertNotEquals () mitte ainult ei aita teil tuvastada, kas kood on täidetud nii, nagu peaks, vaid ka tagama, et kood ei läheks valesti, kui kood läheb valesti.
  • ComprehensiveTest - Testimine peaks hõlmama kõike. Peaksite tegema funktsionaalse testimise, koormustestimise, turvatestimise ja juurutamise testimise.
  • Üksuste testid - Teil peaksid olema ühikutestid, et kontrollida, kas üksikud kirjed annavad õige ja oodatud tulemuse. Kuigi kogu koodi hõlmava hiiglasliku testi kasutamine võib tunduda hea mõte, pange tähele, et loodud tulemusi on raskem siluda ja ebaõnnestumisi raskem mõista. Ühikutest peaks hõlmama väikest testitava funktsionaalsuse alamhulka.
  • Testmasskastid - Hea testikood (päästik, erand või klass) võib olla seotud kuni mitusada kirjet (200 Apexi jaoks). Peaksite seda ära kasutama ja testima lisaks üksikutele dokumentidele ka hulgijuhtumeid.
  • Positiivsed testid - Testige, et veenduda, kas oodatud käitumine toimub kogu eeldatava permutatsiooni kaudu. Test peaks kontrollima, kas kasutaja on vormi õigesti täitnud ja kas ta ei ületanud piire.
  • Negatiivsed testid - Negatiivsete juhtumite testimiseks veenduge, et veateated oleksid õigesti toodetud. Selliste negatiivsete juhtumite näideteks ei ole negatiivsete summade täpsustamine ja tulevaste kuupäevade lisamata jätmine. Negatiivsed testid on olulised, sest õige käitlemine lõunasse minnes võib kõike muuta.
  • Automatiseeri testimine - Traditsiooniliselt oli Salesforce'i testimine käsitsi. Peaksite kaaluma automatiseeritud testimist, kuna see pakub rohkem eeliseid. Need sisaldavad:
    • Käsitsi testimine muudab teid vigadele vastuvõtlikuks, kuna testimine toimub inimeste, mitte robotite poolt. Robotid paistavad silma korduvate tegevustega, samal ajal kui inimesed teevad igavuse, vähenenud keskendumisvõime ja järjepidevuse ning kalduvuse tõttu nurka kalduda vigu.
    • Manuaalne testimine on korduv, vormiline ja väsitav. Testimeeskonnal on parem teha uurimuslikumat tööd.
  • Käivitage iga koodiloogika haru - Tingimusliku loogika kasutamisel (kui olete kaasanud kolmepoolsed operaatorid), tuleks koodiloogika iga haru käivitada.
  • Kasutage meetoditele helistamiseks kehtetuid ja kehtivaid sisendeid - Meetoditele tuleks helistada nii valede kui ka kehtivate sisendite abil.
  • Täielikud testid - Veenduge, et testid oleksid edukalt lõpule viidud - need ei tohiks teha erandeid, välja arvatud juhul, kui vead on eeldatavad. Käsitlege kõiki püütud erandeid - nende tabamine pole piisavalt hea.
  • Kasuta märksõnu ORDER BY - Kasutage märksõnu ORDER BY tagamaks, et teie dokumendid tagastatakse oodatud järjekorras.
  • Ärge eeldage, et dokumendi ID-d järjestatakse järjestikku - Vältige levinud viga, kui eeldatakse, et kirje ID-d on järjestatud järjestusse. ID-d ei ole kasvavas järjekorras, välja arvatud juhul, kui olete sama taotlusega sisestanud mitu kirjet.
  • Helistage test.startTest () ja Test.stopTest () - Apexi üksustesti käivitamisel saate rohkem kui 75% -lise koodi katvuse, mis on Salesforce'is kohustuslik. Enne väidete esitamist helistage stopTest, et asünkroonseid koode, mis võivad veel töötada, lõpetamiseks sundida. Käivitage värsked päringud lõplike tulemuste saamiseks, kuna muu kood võib andmeid muuta. Testi.startTest () ja Test.stopTest () kasutamine tagab testi liivakastis kuvari piirides. Nii ei sekku teie kasutatav seadistuskood ega anna teile vale-negatiivseid või positiivseid andmeid, mis ümbritsevad kuberneri piiranguid. Test.stopTest () tagab ka @future'i kõnede testimise lõpuleviimise.
  • Loetavus - Ühikutestides on loetavus väga oluline. Katse nimed peaksid sisaldama konkreetseid toiminguid ja eeldatavat tulemust. Meetod peaks olema kirjeldav ja lühike. Meetod peaks olema selline, et seda saaks erinevate testide käigus uuesti kasutada.
  • Enne startTesti koostage suured testiandmekogumid - Kuna teie testid töötavad erinevates liivakasti- ja tootmiskeskkondades, koostage enne startTesti helistamist suured testiandmekogumid, et testil oleksid täielikud täitmispiirangud. Algselt, Salesforce Github teeb tootmise andmetest eraldatud katseid. Kui vajate süsteemiandmeid, näiteks profiili, pärige, et saada just selles keskkonnas õige asi.
  • Looge oma testiandmed - Teie kasutatavad testiandmed tuleks testis luua. Neid andmeid saate luua @testSetup märkuse ja klassi TestUtils abil, et mitte ainult tagada õigete andmete olemasolu, vaid ka tagada, et kõik testid töötataks arendaja liivakastis, kus pole andmeid vaja.
  • Vältige AKA null-toiminguid - Paljud testijad kasutavad AKA nulloperatsioone. Need on kasutud koodid, mis ei tee midagi. Kuna need on juba teie koodibaasis, lisavad nad teie katvuse protsenti.
  • Paralleelse testi täitmine - Kui alustate teste Salesforce'i kasutajaliidese või arendajakonsooli kaudu, töötavad testid paralleelselt. See on oluline funktsioon, kuna see kiirendab testkäigu aega. Peaksite siiski arvestama, et see võib põhjustada andmevaidluse probleeme ja kui kahtlustate, et see võib juhtuda, lülitage paralleelne täitmine välja. Andmekonkursi probleemide kõige sagedasemad põhjused, mis sageli põhjustavad UNABLE_TO_LOCK_ROW tõrkeid, on järgmised:
    • Kui testide eesmärk on värskendada samu kirjeid samaaegselt. Samade kirjete uuendamine toimub tavaliselt siis, kui testid ei loo oma andmeid.
    • Kui paralleelselt töötavates testides on ummikseis ja nad üritavad luua kirjeid, millel on vastavad indeksivälja väärtused. Ummik tekib siis, kui andmete jooksvaks muutmiseks on järjekorras 2 jooksvat testi (see juhtub siis, kui 2 testib sisendkirjeid, millel on ühesugused unikaalsed indeksivälja väärtused erinevates järjestustes).
    • Paralleelse testi käivitamise väljalülitamiseks minge seadistusse, sisestage Apex Test, minge dialoogi Apex Test Execution suvanditega, valige Disable Parallel Apex Testing, klõpsake nuppu OK.

Keela paralleelse tipu testimine

Palgake selle töö jaoks proff, kuna tal on hea testi tegemiseks vajalik kogemus ja väljaõpe, mis annab teile ka meelerahu. Profi palkamine võimaldab teil keskenduda oma põhitegevusele. See säästab ka teie raha, kuna teil pole selle töö jaoks vaja ettevõttesisest meeskonda.

Mis sa arvad?

Sellel saidil kasutatakse rämpsposti vähendamiseks Akismetit. Vaadake, kuidas teie andmeid töödeldakse.