Tips og beste fremgangsmåter for testing av Salesforce-integrasjoner

salgsstyrkeintegrasjon

Salesforce-testing hjelper deg med å validere din tilpassede Salesforce-integrasjoner og funksjonalitet med andre bedriftsapplikasjoner. En god test dekker alle Salesforce-moduler fra kontoer til potensielle kunder, fra muligheter til rapporter og fra kampanjer til kontakter. Som det er tilfelle med alle tester, er det en god (effektiv og effektiv) måte å gjøre en Salesforce-test og en dårlig måte. Så, hva tester Salesforce god praksis?

  • Bruk riktig testverktøy - Salesforce-testing skjer i nettleseren eller i et formørkelsesbasert miljø. Både de nyeste nettleserne og formørkelsen har gode feilsøkingsverktøy, og du kan kombinere disse med testklasser for å få svært nyttige resultater. Imidlertid, hvis du trenger mer, bør Apex Interactive Debugger (eller bare Apex) fra Force.com brukes. Merk at du også kan bruke Salesforce Lightning Inspector, en kromutvidelse, for å teste Salesforce Lightning spesifikt. Apex er en Force.com plattforms proprietært programmeringsspråk som har store likheter med Java. Det er et objektorientert, store og små bokstaver, sterkt types programmeringsspråk som følger krøllete parenteser og punktnotasjonssyntaks. Du kan bruke Apex til å utføre programmerte funksjoner under de fleste Force.com-prosesser, inkludert tilpassede lenker og knapper, oppdateringer, slettinger og registrere innsettingshendelseshåndterere gjennom Visualforce-sidens tilpassede kontrollere eller planlegging.
  • Bruk ordninger for riktig navning - Riktig navngivning av testmetodene dine før du begynner å skrive tester er veldig viktig. Testmetodenavnet skal ha tre deler. Dette er nameOfMethod (navnet på den enkelte metoden du tester, for eksempel sett inn / oppdater / slett / angre når du tester en trigger, informasjon om TestPath som er fleksibel, for eksempel nullkontakt hvis du tester at kontakten er null, og gyldig når du tester en positiv / negativ vei.
  • Sikre 100% dekning - Selv om det vanlige Salesforce-direktivet er at enhetstest skal ha en dekning på 75% av koden din (minus testklasser, samtaler til System.debug og testmetoder), og du ikke vil kunne distribuere Apex-kode eller pakke AppExchange-apper, bør du Vær oppmerksom på at dette bare er en standard, og målet ditt skal være 100% dekning. Test alle positive / negative tilfeller og for data som er tilstede og ikke er til stede. Andre viktige tips når det gjelder kodedekning er:
    • Du bør kjøre tester for å oppdatere kodedekningsnumre, siden disse tallene ikke oppdateres når Apex-koden oppdateres til testene kjøres på nytt.
    • Hvis det har vært en oppdatering i organisasjonen siden forrige testkjøring, er det en risiko for at kodedekningstallene blir feil. Kjør testene for riktig estimat.
    • Kodedekningsprosenten inkluderer ikke kodedekning fra tester av administrerte pakker, med det eneste unntaket når disse testene får utløserne til å utløses.
    • Dekningen avhenger av det totale antallet kodelinjer. Hvis du legger til eller sletter kodelinjer, vil du påvirke prosentandelen.
  • Test tilfeller i klasser og kontrollere - I Salesforce-utvikling lager de fleste utviklere separate klasser og kontrollerfiler for hver funksjon. Dette gjøres for å gjøre kodingen mer organisert, enklere, gjenbrukbar og bærbar. Du bør imidlertid merke deg at selv om dette er lettere, er det ikke mer effektivt. Du vil oppnå bærbarhet hvis testkoden er i den opprinnelige klassen og selve kontrollerkoden, siden du ikke vil gå glipp av noen testklasse når du migrerer fra sandkasse til produksjon.
  • Bruk System.assert () - I Apex, System.assert() brukes til å kontrollere forholdene. Dette er en viktig funksjonalitet siden den lar deg bestemme om en bestemt funksjon er utført av metoden som forventet. Du bør bruke System.assertEquals () og System.assertNotEquals () mellom viktige funksjoner, hjelper deg ikke bare med å avgjøre om koden er utført som den skal, men for å sikre at ingen data blir skrevet feil hvis koden går galt.
  • Omfattende test - Testing skal dekke alt. Du bør utføre funksjonstesting, belastningstesting, sikkerhetstesting og distribusjonstesting.
  • Enhetstester - Du bør ha enhetstester for å verifisere at individuelle poster gir riktig og forventet resultat. Mens du bruker en gigantisk test som dekker hele koden, kan det virke som en god idé, men vær oppmerksom på at resultatene som genereres vil være vanskeligere å feilsøke, og feil vil være vanskeligere å forstå. En enhetstest skal dekke en liten delmengde av funksjonaliteten som testes.
  • Test bulk tilfeller - En god testkode (trigger, unntak eller klasse) kan være involvert i opptil flere hundre poster (200 for Apex). Du bør dra nytte av dette og teste ikke bare individuelle poster, men også massesaker.
  • Positive tester - Test for å sikre om forventet oppførsel skjer gjennom all forventet permutasjon. Testen skal verifisere at brukeren fylte ut skjemaet riktig, og at han / hun ikke gikk over grensene.
  • Negative tester - Test de negative tilfellene for å sikre at feilmeldinger produseres riktig. Eksempler på slike negative tilfeller er ikke å kunne spesifisere negative beløp og ikke å kunne legge til fremtidige datoer. Negative tester er viktige fordi riktig håndtering når ting går sørover kan utgjøre hele forskjellen.
  • Automatiser testing - Tradisjonelt var Salesforce-testing manuell. Du bør vurdere automatisert testing, da dette gir flere fordeler. Disse inkluderer:
    • Manuell testing gjør at du er utsatt for feil siden testing er av mennesker og ikke av roboter. Roboter utmerker seg ved repeterende aktiviteter mens mennesker gjør feil på grunn av kjedsomhet, redusert konsentrasjon og konsistens og en tendens til å kutte hjørner.
    • Manuell testing er repeterende, formell og slitsom. Testteamet har det bedre å utføre arbeid som er mer utforskende.
  • Utfør hver kodelogisk gren - Når du bruker betinget logikk (når du har tatt med ternære operatører), bør hver gren av kodelogikken utføres.
  • Bruk ugyldige og gyldige innganger for samtaler til metoder - Anrop til metoder bør ringes med både ugyldige og gyldige innganger.
  • Fullfør tester - Forsikre deg om at testene gjennomføres vellykket - de bør ikke gjennom noen unntak med mindre feilene forventes. Håndter alle unntak som er fanget - å fange dem er ikke bra nok.
  • Bruk ORDER BY Keywords - For å sikre at postene dine returneres i den rekkefølgen du forventer, bruker du ORDER BY-nøkkelordene.
  • Anta ikke at ID-er blir ordnet i rekkefølge - Unngå den vanlige feilen å anta at post-ID er ordnet i sekvensiell rekkefølge. IDene er ikke i stigende rekkefølge, med mindre du har satt inn flere poster med samme forespørsel.
  • Ring Test.startTest () og Test.stopTest () - Når du kjører en Apex-enhetstest, får du mer enn 75% kodedekning som er obligatorisk i Salesforce. Du bør ringe stopTest før påstander for å tvinge asynkrone koder som fortsatt kan kjøre til slutt. Kjør nye spørsmål for endelige resultater siden annen kode kan endre data. UsingTest.startTest () og Test.stopTest () sikrer at du sandkasser testen innen regulatorens grenser. På denne måten vil oppsettkoden du bruker ikke forstyrre og gi deg falske negativer eller positive ting rundt guvernørens grenser. Test.stopTest () sørger også for at @future-samtaler blir fullført for testing.
  • Lesbarhet - Lesbarhet er veldig viktig i enhetstester. Testnavnene skal inneholde den spesifikke handlingen som skal utføres og det forventede resultatet. Metoden skal være beskrivende og kort. Metoden skal være slik at den kan gjenbrukes på tvers av forskjellige tester.
  • Bygg store testdatasett før startTest - Siden testene dine kjører i forskjellige sandkasse- og produksjonsmiljøer, må du bygge store testdatasett før du ringer til startTest for å sikre at testen har full utførelsesgrenser. Som standard, Salesforce Github kjører tester isolert fra produksjonsdata. Når du trenger systemdata som en profil, kan du spørre deg for å få det rette for det spesifikke miljøet.
  • Generer dine egne testdata - Testdataene du bruker, skal genereres i testen. Du kan generere disse dataene ved hjelp av @testSetup-kommentar og en TestUtils-klasse for ikke bare å sikre at du har de riktige dataene, men også for å sikre at alle testene kjøres på en utviklersandkasse uten krav til data.
  • Unngå no-op AKA nulloperasjoner - Mange testere bruker ikke-op AKA nulloperasjoner. Dette er ubrukelige koder som ikke gjør noe. Siden de allerede er i kodebasen din, vil de legge til dekningsprosenten din.
  • Parallell testutførelse - Når du starter tester fra Salesforce-brukergrensesnittet eller utviklerkonsollen, vil testene kjøre parallelt. Dette er en viktig funksjon ettersom den fremskynder testkjøringstiden. Du bør imidlertid være oppmerksom på at dette kan føre til problemer med datakonflikt, og hvis du mistenker at dette kan skje, slå av parallell kjøring. De vanligste årsakene til problemer med datakonflikt som ofte fører til UNABLE_TO_LOCK_ROW feil er:
    • Når tester er ment å oppdatere de samme postene samtidig. Oppdatering av de samme postene skjer vanligvis når tester ikke lager sine egne data.
    • Når det er låsing i tester som kjører parallelt, og de prøver å lage poster som har samsvarende indeksfeltverdier. En fastlåsing vil oppstå når to kjørende tester har stått i kø for å rulle tilbake data (dette skjer når to tester inngangsposter som har de samme unike indeksfeltverdiene i forskjellige ordrer).
    • For å slå av parallell testutførelse, gå til Oppsett, gå inn i Apex Test, gå til Apex Test Execution Options dialog, velg Deaktiver Parallel Apex Testing, klikk OK.

Deaktiver Parallel Apex Testing

Ansett en proff for jobben siden han vil ha den erfaring og trening som er nødvendig for å gjøre en god test, som også gir deg sjelefred. Ved å ansette en proff kan du konsentrere deg om kjernevirksomheten. Det sparer deg også penger siden du ikke trenger et internt team for jobben.

Hva tror du?

Dette nettstedet bruker Akismet for å redusere spam. Lær hvordan kommentaren din behandles.