Vinkkejä ja parhaita käytäntöjä Salesforce-integraatioiden testaamiseen

Salesforce-integraatio

Salesforce-testaus auttaa sinua vahvistamaan räätälöidyt Salesforce-integraatiot ja toiminnallisuudet muiden yrityssovellusten kanssa. Hyvä testi kattaa kaikki Salesforce-moduulit tileistä liideihin, mahdollisuuksista raportteihin ja kampanjoista kontakteihin. Kuten kaikkien testien kohdalla, on hyvä (tehokas ja tehokas) tapa tehdä Salesforce-testi ja huono tapa. Joten mitä Salesforce testaa hyviä käytäntöjä?

  • Käytä oikeita testaustyökaluja - Salesforce-testaus tapahtuu selaimessa tai eclipse-pohjaisessa ympäristössä. Sekä uusimmissa selaimissa että pimennyksissä on hyvät virheenkorjaustyökalut, ja voit yhdistää ne testiluokkiin saadaksesi erittäin hyödyllisiä tuloksia. Jos tarvitset enemmän, Force.comin tulisi käyttää The Apex Interactive Debugger (tai yksinkertaisesti Apex). Huomaa, että voit myös käyttää Salesforce Lightning Inspectoria, kromilaajennusta, testata erityisesti Salesforce Lightningia. Apex on a Force.com alustan oma ohjelmointikieli, jolla on suuria yhtäläisyyksiä Java: n kanssa. Se on olioihin suuntautunut, kirjainkoon erottamaton, voimakkaasti tyyppinen ohjelmointikieli, joka seuraa kiharasulkeita ja pistemerkintäsyntaksia. Apexin avulla voit suorittaa ohjelmoidut toiminnot useimpien Force.com-prosessien aikana, mukaan lukien mukautetut linkit ja painikkeet, päivitykset, poistot ja tietueiden lisäystapahtumien käsittelijät Visualforce-sivun mukautettujen ohjaimien tai ajoituksen kautta.
  • Käytä oikeita nimeämistapoja - Testimenetelmien oikea nimeäminen ennen testien kirjoittamisen aloittamista on erittäin tärkeää. Testimenetelmän nimessä on oltava kolme osaa. Nämä ovat nameOfMethod (testattavan menetelmän nimi, kuten insert / update / delete / undelete testattaessa liipaisinta, tiedot TestPathista, joka on joustavaa, kuten null contact, jos testaat, että kontakti on null, ja kelvollinen testattaessa positiivinen / negatiivinen polku.
  • Varmista 100% kattavuus - Vaikka tavallinen Salesforce-direktiivi on, että yksikkötestin tulisi peittää 75% koodistasi (miinus testiluokat, puhelut System.debugille ja testimenetelmät), etkä voi käyttää Apex-koodia tai AppExchange-sovelluksia, sinun tulisi Huomaa, että tämä on vain standardi ja tavoitteesi tulisi olla 100% kattavuus. Testaa kaikki positiiviset / negatiiviset tapaukset ja läsnä olevat tiedot, joita ei ole. Muita tärkeitä vinkkejä koodin kattavuudesta ovat:
    • Päivitä koodin kattavuusnumerot suorittamalla testit, koska näitä numeroita ei päivitetä Apex-koodia päivitettäessä, kunnes testit suoritetaan uudelleen.
    • Jos organisaatiossa on päivitetty viimeisen testiajon jälkeen, on olemassa vaara, että koodin peittonumerot ovat väärät. Suorita testit uudelleen oikean estimaatin saamiseksi.
    • Koodin kattavuusprosentti ei sisällä hallittujen pakettien testien koodia, ainoa poikkeus on, että nämä testit aiheuttavat laukaisijoiden laukaisun.
    • Kattavuus riippuu koodirivien kokonaismäärästä. Jos lisäät tai poistat koodirivejä, muutat prosenttiosuutta.
  • Testikotelot luokissa ja ohjaimissa - Salesforce-kehityksessä useimmat kehittäjät luovat erilliset luokat ja ohjaintiedostot kullekin toiminnolle. Tämä tehdään koodauksen organisoidummaksi, helpommaksi, uudelleenkäytettävämmäksi ja kannettavammaksi. Huomaa kuitenkin, että vaikka tämä on helpompaa, se ei ole tehokkaampaa. Voit saavuttaa siirrettävyyden, jos testikoodi on alkuperäisessä luokassa ja itse ohjainkoodissa, koska et menetä mitään testiluokkaa siirtyessäsi hiekkalaatikosta tuotantoon.
  • Käytä System.assert () - Apexissa Järjestelmä. Ilmoitus() käytetään olosuhteiden tarkistamiseen. Tämä on tärkeä toiminto, koska sen avulla voit määrittää, onko tietty toiminto suoritettu menetelmällä odotetusti. Käytä kriittisten toimintojen välillä System.assertEquals () ja System.assertNotEquals () paitsi auttaa sinua selvittämään, onko koodi suoritettu oikein, vaan myös varmistamaan, että tietoja ei kirjoiteta virheellisesti, jos koodi menee pieleen.
  • Kattava testi - Testauksen tulisi kattaa kaikki. Sinun tulisi tehdä toiminnallinen testaus, kuormitustestaus, tietoturvatestaus ja käyttöönoton testaus.
  • Yksikkötestit - Sinulla on oltava yksikkötestit varmistaaksesi, että yksittäiset tietueet tuottavat oikean ja odotetun tuloksen. Vaikka koko koodin kattavan jättimäisen testin käyttäminen saattaa tuntua hyvältä ajatukselta, huomaa, että saatuja tuloksia on vaikeampi virheenkorjaus ja epäonnistumisia on vaikeampaa ymmärtää. Yksikkötestin tulisi kattaa pieni osa testattavista toiminnoista.
  • Testaa irtotavarakotelot - Hyvä testikoodi (liipaisin, poikkeus tai luokka) voi olla mukana jopa useita satoja tietueita varten (200 Apexille). Sinun tulisi hyödyntää tätä ja testata paitsi yksittäiset tietueet myös joukkotapaukset.
  • Positiiviset testit - Testaa varmistaaksesi, että odotettu käyttäytyminen tapahtuu kaiken odotetun permutaation kautta. Testin tulisi varmistaa, että käyttäjä on täyttänyt lomakkeen oikein ja ettei hän ylittänyt rajoja.
  • Negatiiviset testit - Testaa negatiiviset tapaukset varmistaaksesi, että virheilmoitukset tuotetaan oikein. Esimerkkejä tällaisista negatiivisista tapauksista eivät ole kykeneviä määrittämään negatiivisia summia eivätkä lisäämään tulevia päivämääriä. Negatiiviset testit ovat tärkeitä, koska oikea käsittely, kun asiat menevät etelään, voivat tehdä kaiken.
  • Automatisoi testaus - Perinteisesti Salesforcen testaus oli manuaalista. Harkitse automaattista testausta, koska se tarjoaa enemmän etuja. Nämä sisältävät:
    • Manuaalinen testaus tekee sinusta alttiita virheille, koska testaus tapahtuu ihmisten eikä robottien toimesta. Robotit menestyvät toistuvassa toiminnassa, kun ihmiset tekevät virheitä ikävyydestä, vähentyneestä keskittymiskyvystä ja johdonmukaisuudesta sekä taipumuksesta leikata kulmia.
    • Manuaalinen testaus on toistuvaa, kaavamaista ja väsyttävää. Testausryhmällä on parempi tehdä tutkimuksellisempaa työtä.
  • Suorita kukin Code Logic Branch - Kun käytetään ehdollista logiikkaa (kun olet sisällyttänyt kolmikertaiset operaattorit), koodilogiikan kukin haara tulisi suorittaa.
  • Käytä virheellisiä ja kelvollisia syötteitä menetelmäkutsuihin - Menetelmäkutsujen tulisi tapahtua sekä virheellisten että kelvollisten syötteiden avulla.
  • Täydelliset testit - Varmista, että testit suoritetaan onnistuneesti - niiden ei pitäisi tehdä poikkeuksia, ellei virheitä odoteta. Käsittele kaikki kiinni jääneet poikkeukset - niiden saaminen ei ole tarpeeksi hyvää.
  • Käytä ORDER BY -avainsanoja - Käytä ORDER BY avainsanoja varmistaaksesi, että tietueesi palautetaan odotetussa järjestyksessä.
  • Älä oleta, että tietueiden tunnukset järjestetään peräkkäin - Vältä yleistä virhettä olettaen, että tietuetunnukset on järjestetty peräkkäin. Tunnukset eivät ole nousevassa järjestyksessä, ellet ole lisännyt useita tietueita samalla pyynnöllä.
  • Kutsu Test.startTest () ja Test.stopTest () - Kun suoritat Apex-yksikötestin, saat yli 75%: n koodikattavuuden, joka on pakollinen Salesforcessa. Sinun on kutsuttava stopTest ennen väitteitä pakottaaksesi asynkroniset koodit, jotka saattavat vielä olla käynnissä, loppuun. Suorita uusia kyselyitä lopullisista tuloksista, koska muu koodi saattaa muuttaa tietoja. UsingTest.startTest () ja Test.stopTest () varmistavat, että testi hiekkalaatikkoon kuuluu kuvernöörin rajoissa. Tällä tavoin käyttämäsi asennuskoodi ei häiritse ja antaa sinulle vääriä negatiivisia tai positiivisia piirteitä, jotka ympäröivät kuvernöörin rajoja. Test.stopTest () varmistaa myös, että @future-puhelut suoritetaan testausta varten.
  • Luettavuus - Luettavuus on erittäin tärkeää yksikötesteissä. Testinimien tulisi sisältää toteutettava toimenpide ja odotettu tulos. Menetelmän tulisi olla kuvaileva ja lyhyt. Menetelmän tulisi olla sellainen, että sitä voidaan käyttää uudelleen eri testeissä.
  • Rakenna suuria testitietojoukkoja ennen startTestia - Koska testisi ajetaan eri hiekkalaatikko- ja tuotantoympäristöissä, luo suuret testitietojoukot ennen startTest-kutsua varmistaaksesi, että testillä on täydet suoritusrajat. Oletuksena, Salesforce Github suorittaa tuotantotiedoista eristettyjä testejä. Kun tarvitset järjestelmätiedot, kuten Profiili, kysele saadaksesi oikean asian kyseiseen ympäristöön.
  • Luo oma testitieto - Käyttämäsi testitiedot tulisi luoda testissä. Voit luoda nämä tiedot käyttämällä @testSetup-merkintää ja TestUtils-luokkaa varmistaaksesi, että sinulla on vain oikeat tiedot, mutta myös varmistaa, että kaikki testit suoritetaan kehittäjän hiekkalaatikossa ilman tietovaatimuksia.
  • Vältä toimimattomia AKA-nollaoperaatioita - Monet testaajat käyttävät AKA: n tyhjäkäyntejä. Nämä ovat hyödyttömiä koodeja, jotka eivät tee mitään. Koska ne ovat jo koodikannassasi, ne lisäävät kattavuusprosenttisi.
  • Rinnakkaistestin suorittaminen - Kun aloitat testit Salesforcen käyttöliittymästä tai kehittäjäkonsolista, testit suoritetaan rinnakkain. Tämä on tärkeä ominaisuus, koska se nopeuttaa koeaikaa. Huomaa kuitenkin, että tämä voi johtaa tietokilpailuongelmiin, ja jos epäilet, että näin voi tapahtua, poista rinnakkainen suoritus. Yleisimmät tietokilpailuongelmien syyt, jotka johtavat usein UNABLE_TO_LOCK_ROW -virheisiin, ovat:
    • Kun testien on tarkoitus päivittää samat tietueet samanaikaisesti. Samojen tietueiden päivitys tapahtuu yleensä silloin, kun testit eivät luo omia tietojaan.
    • Kun rinnakkain toimivissa testeissä on umpikuja ja he yrittävät luoda tietueita, joilla on vastaavat hakemistokenttäarvot. Umpilukko tapahtuu, kun 2 käynnissä olevaa testiä on jonossa tietojen palauttamiseksi (tämä tapahtuu, kun 2 testaa syötetietueita, joilla on samat ainutlaatuiset hakemistokenttäarvot eri järjestyksissä).
    • Sammuta rinnakkaistestin suoritus siirtymällä Asetusohjelmaan, kirjoittamalla Apex Test, siirtymällä Apex Test Execution Options -valintaikkunaan, valitsemalla Disable Parallel Apex Testing ja napsauttamalla OK.

Poista Rinnakkaishuiputestaus käytöstä

Palkkaa ammattilainen työhön, koska hänellä on kokemusta ja koulutusta hyvän testin tekemiseen, mikä antaa sinulle myös mielenrauhaa. Ammattilaisen palkkaaminen antaa sinun keskittyä ydinliiketoimintaan. Se säästää myös rahaa, koska et tarvitse sisäistä tiimiä työhön.

Mitä mieltä olet?

Tämä sivusto käyttää Akismetiä roskapostin vähentämiseksi. Lue, miten kommenttitietosi käsitellään.