Salesforce integrazioak probatzeko aholkuak eta jardunbide egokiak

salesforce integrazioa

Salesforce probak pertsonalizatuak balioztatzen lagunduko dizu Salesforce integrazioak eta beste enpresa aplikazio batzuekin funtzionalitateak. Proba on batek Salesforce-ren modulu guztiak hartzen ditu kontuan, hasieratik, aukerak, txostenak eta kanpainak eta kontaktuak. Proba guztietan gertatzen den bezala, Salesforce proba egiteko modu ona (eraginkorra eta eraginkorra) dago eta modu txarra. Orduan, zer da Salesforce probatzen ari den praktika ona?

  • Erabili probatzeko tresna egokiak - Salesforce probak arakatzailean edo eklipseetan oinarritutako ingurune batean gertatzen dira. Azken arakatzaileek eta eklipseak arazketa tresna bikainak dituzte eta hauek proba klaseekin konbinatu ditzakezu emaitza oso lagungarriak lortzeko. Hala ere, gehiago behar izanez gero, Force.com-ek egindako Apex Interactive Debugger (edo, besterik gabe, Apex) erabili beharko litzateke. Kontuan izan Salesforce Lightning Inspector ere erabil daitekeela, kromoko luzapena, Salesforce Lightning berariaz probatzeko. Apex da Force.com plataformaren jabedun programazio lengoaia, Java-rekin antzekotasun handiak dituena. Objektuei zuzendutakoa, maiuskulak eta minuskulak bereizten ez dituena, oso motako programazio lengoaia da, kakotxak eta puntu-notazio sintaxia jarraitzen dituena. Apex erabil dezakezu Force.com-eko prozesu gehienetan programatutako funtzioak exekutatzeko, esteka eta botoi pertsonalizatuak, eguneratzeak, ezabatzeak eta erregistroak txertatzeko gertaeren kudeatzaileak barne, Visualforce orrialdearen kontrolagailu pertsonalizatuen edo programazioaren bidez.
  • Erabili izen egokien hitzarmenak - Probak idazten hasi aurretik zure metodoen izendapen egokia ematea oso garrantzitsua da. Proba metodoaren izenak hiru zati izan behar ditu. Hauek dira nameOfMethod (probatzen ari zaren metodo indibidualaren izena, hala nola txertatu / eguneratu / ezabatu / berreskuratu abiarazle bat probatzean, TestPath-i buruzko informazioa, hau da, kontaktu nulua bezalako informazioa, kontaktu nulua probatzen baduzu eta baliozkoa probatzerakoan bide positiboa / negatiboa.
  • Bermatu% 100eko estaldura - Salesforce zuzentarau estandarrak dioenez, unitateko probak zure kodearen% 75eko estaldura izan beharko luke (ken klaseak, System.debug-era deiak eta proba metodoak) eta ezin izango duzu Apex kodea edo AppExchange aplikazioak paketatu inplementatu, Kontuan izan hori estandar bat besterik ez dela eta zure helburua% 100eko estaldura izan beharko lukeela. Probatu kasu positibo / negatibo guztiak eta dauden eta ez dauden datuak. Kodearen estaldurari dagokionez beste aholku garrantzitsu batzuk hauek dira:
    • Kodeak estaltzeko zenbakiak freskatzeko probak egin beharko zenituzke, Apex kodea eguneratzen denean zenbaki horiek ez baitira freskatzen probak berriro exekutatu arte.
    • Azken proba egin zenetik erakundean eguneratzerik egon bada, kodeen estaldura zenbakiak okerrak izateko arriskua dago. Berriro egin probak estimazio egokia lortzeko.
    • Kodeen estaldura portzentajeak ez du kudeatutako paketeen proben kode estaldura barne, salbuespen bakarra izanik proba horiek abiarazleak pizten dituztenean.
    • Estaldura kode lerro kopuru osoaren araberakoa da. Kode lerroak gehitzen edo ezabatzen badituzu, ehunekoan eragina izango duzu.
  • Probak kasuak klaseetan eta kontrolagailuetan - Salesforce garapenean, garatzaile gehienek funtzio bakoitzerako klase eta kontrolagailu fitxategiak sortzen dituzte. Kodeketa antolatuagoa, errazagoa, berrerabilgarriagoa eta eramangarriagoa izan dadin egiten da. Hala ere, kontuan izan behar duzu hori errazagoa den arren, ez dela eraginkorragoa. Eramangarritasuna lortuko duzu testaren kodea jatorrizko klasean eta kontroladorearen kodean bertan badago, proba-klaserik ez baduzu galduko sandbox-etik ekoizpenera migratzean.
  • Erabili System.assert () - Apex-en, Sistema.baieztatu() baldintzak egiaztatzeko erabiltzen da. Funtzionalitate garrantzitsua da, metodoaren arabera funtzio jakin bat espero den bezala egin den ala ez zehazteko aukera ematen baitu. Funtzionalitate kritikoen artean System.assertEquals () eta System.assertNotEquals () erabili beharko zenituzke, kodea behar bezala exekutatu den ala ez zehazten lagunduko dizu, baita kodea gaizki ateratzen den datuak ez direla gaizki idazten ere ziurtatzen.
  • Proba Integrala - Probak dena estali behar du. Proba funtzionalak, karga probak, segurtasun probak eta hedapen probak egin beharko zenituzke.
  • Unitate Probak - Unitateko probak egin beharko zenituzke, banakako erregistroek emaitza zuzena eta itxarondakoa sortzen dutela egiaztatzeko. Kode osoa estaltzen duen proba erraldoi bat erabiltzeak ideia ona dirudien arren, kontuan izan sortutako emaitzak zailagoak izango direla arazteko eta porrota ulertzeko zailagoa izango dela. Unitate-probak probatzen ari den funtzionalitatearen azpimultzo txiki bat estali behar du.
  • Probako Bulk Kasuak - Proba-kode on batek (abiarazlea, salbuespena edo klasea) ehunka erregistroan parte har dezake (200 Apex) Hori aprobetxatu eta banakako erregistroak ez ezik, kasu handiak ere probatu beharko zenituzke.
  • Proba positiboak - Probatu espero den portaera espero den permutazio guztiaren bidez gertatzen den ala ez ziurtatzeko. Probak egiaztatu beharko du erabiltzaileak inprimakia behar bezala bete duela eta ez duela mugak gainditzen.
  • Proba negatiboak - Probatu kasu negatiboak errore mezuak zuzen sortzen direla ziurtatzeko. Kasu negatibo horien adibideak ez dira zenbateko negatiboak zehaztu eta etorkizuneko datak gehitzeko gai ez izatea. Proba negatiboak garrantzitsuak dira, gauzak hegoaldera doazenean manipulazio zuzena aldea izan baitaiteke.
  • Probak automatizatu - Tradizionalki, Salesforce probak eskuz egiten ziren. Probak automatizatzea kontuan hartu beharko zenuke horrek abantaila gehiago eskaintzen baititu. Hauek dira:
    • Eskuz egindako probek akatsen aurrean sentikorra bihurtzen zaituzte, probak gizakiek egiten dituztelako eta ez robotek. Robotak jarduera errepikakorretan bikain daude gizakiek aspertzeagatik, kontzentrazio eta koherentzia murriztuagatik eta izkinak mozteko joeragatik akatsak egiten dituzten bitartean.
    • Eskuzko probak errepikakorrak, formulagarriak eta nekagarriak dira. Probako taldea hobe da esplorazio gehiago egiten duen lana egitea.
  • Exekutatu Code Logic adar bakoitza - Baldintzazko logika erabiltzerakoan (ternario operadoreak sartu dituzunean), kodearen logikaren adar bakoitza exekutatu beharko litzateke.
  • Erabili sarrera baliogabeak eta baliozkoak metodoetarako deietarako - Metodoetarako deiak sarrera baliogabeak eta baliozkoak erabiliz egin beharko lirateke.
  • Proba Osatuak - Ziurtatu probak ongi burutzen direla, ez lukete salbuespenik egin behar akatsak espero ez diren bitartean. Maneiatu harrapatutako salbuespen guztiak - horiek harrapatzea ez da nahikoa ona.
  • Erabili ORDER BY Keywords - Zure erregistroak espero zenuen ordenan itzultzen direla ziurtatzeko, erabili ORDER BY keywords.
  • Ez pentsa Erregistro IDak sekuentzialki antolatuta daudela - Saihestu erregistro IDak sekuentzialean antolatuta daudela suposatzearen ohiko akatsa. Identifikazioak ez daude goranzko ordenan, eskaera berarekin erregistro bat baino gehiago sartu ez badituzu behintzat.
  • Deitu Test.startTest () eta Test.stopTest () - Apex unitate-proba egiten duzunean, Salesforce-n derrigorrezkoa den% 75eko kode estaldura baino gehiago lortuko duzu. Baieztapenen aurretik stopTest deitu beharko zenuke oraindik exekutatzen ari diren kode asinkronoak amaitzera behartzeko. Exekutatu kontsulta berriak azken emaitzak lortzeko, beste kode batzuek datuak alda ditzaketelako. UseTest.startTest () eta Test.stopTest () erabilita probak bere gobernadorearen mugen barruan probatzea bermatuko duzu. Modu honetan, erabiltzen duzun konfigurazio kodeak ez du oztopatuko eta ez dizkizu gobernadorearen mugen inguruko negatibo edo positibo faltsuak emango. Test.stopTest () -ek ere ziurtatzen du @future deiak probak egiteko osatuko direla.
  • Irakurgarritasuna - Irakurgaitasuna oso garrantzitsua da unitateko probetan. Probaren izenek egin beharreko ekintza zehatza eta espero den emaitza jaso beharko dituzte. Metodoak deskribatzailea eta laburra izan behar du. Metodoak proba desberdinetan berrerabiltzeko modukoa izan behar du.
  • Sortu proba handien datu multzoak startTest aurretik - Probak sandbox eta produkzio ingurune desberdinetan exekutatuko direnez, sortu proba datu multzo handiak startTest deitu aurretik, probak exekuzio muga osoa duela ziurtatzeko. Lehenetsiz, Salesforce Github produkzio datuetatik isolatutako probak egiten ditu. Profila bezalako sistemako datuak behar dituzunean, egin kontsulta ingurune zehatz horretarako gauza egokia lortzeko.
  • Sortu zeure probako datuak - Erabiltzen dituzun proben datuak proban sortu beharko lirateke. Datu hauek sor ditzakezu @ testSetup oharpenaren bidez eta TestUtils klasea erabiliz, datu zuzenak dituzula ziurtatzeko, baita proba guztiak garatzailearen sandbox batean exekutatuko direla ziurtatzeko ere, datuen beharrik gabe.
  • Saihestu oparorik gabeko AKA eragiketa nuluak - Probatzaile askok AKA gabeko operazio nuluak erabiltzen dituzte. Ezertarako balio ez duten alferrikako kodeak dira. Dagoeneko zure kodearen oinarrian daudenez, zure estaldura ehunekoa gehituko dute.
  • Test paraleloaren exekuzioa - Salesforce erabiltzailearen interfazetik edo Garatzaile kontsolatik probak hasten dituzunean, probak paraleloan egingo dira. Ezaugarri garrantzitsua da, proba-denbora azkartzen baitu. Hala ere, kontuan izan behar duzu horrek datuen eztabaida arazoak sor ditzakeela eta hori gerta daitekeela susmatzen baduzu, desaktibatu exekuzio paraleloa. Hauek dira maiz UNABLE_TO_LOCK_ROW akatsak ekartzen dituzten datuen eztabaidarako arazoen kausa ohikoenak:
    • Probek erregistro berberak eguneratu nahi dituztenean. Erregistro berdinak eguneratzea probetan beren datuak sortzen ez dituztenean gertatu ohi da.
    • Paraleloki exekutatzen diren probetan blokeoa dagoenean eta aurkibidearen eremuko balioekin bat datozen erregistroak sortzen saiatzen direnean. Blokeoa gertatuko da exekutatzen ari diren 2 proba ilaran daudenean datuak atzera botatzeko (hau gertatzen da indize-eremuaren balio berezi bakarra duten ordena desberdinetan sarrera-erregistroak probatzean).
    • Proba paraleloen exekuzioa desaktibatzeko, joan Konfigurazioa atalera, sartu Apex proba, joan Apex proba exekuzioaren aukerak elkarrizketa-koadroan, hautatu Desgaitu paraleloaren apex proba, egin klik Ados botoian.

Desgaitu Apex paraleloaren proba

Kontratatu profesional bat lanerako, proba ona egiteko beharrezko esperientzia eta trebakuntza izango dituelako, eta horrek lasaitasuna ere emango dizu. Profesionala kontratatzeak zure oinarrizko negozioan kontzentratzeko aukera ematen dizu. Gainera, dirua aurreztuko duzu, lanerako etxeko talderik ez baituzu beharko.

Zer deritzozu?

Gune honek Akismet-ek spam erabiltzen du. Ikasi zure iruzkina nola prozesatu den.