Tips og bedste praksis til test af Salesforce-integrationer

integration af salgsstyrken

Salesforce-test hjælper dig med at validere din tilpassede Salesforce-integrationer og funktionaliteter med andre virksomhedsapplikationer. En god test dækker alle Salesforce-moduler fra konti til kundeemne, fra muligheder til rapporter og fra kampagner til kontakter. Som det er tilfældet med alle tests, er der en god (effektiv og effektiv) måde at udføre en Salesforce-test på og en dårlig måde. Så hvad tester Salesforce god praksis?

  • Brug de rigtige testværktøjer - Salesforce-test sker i browseren eller i et formørkelsesbaseret miljø. Både de nyeste browsere og eclipse har fantastiske fejlfindingsværktøjer, og du kan kombinere disse med testklasser for at få meget nyttige resultater. Men hvis du har brug for mere, skal Apex Interactive Debugger (eller simpelthen Apex) fra Force.com bruges. Bemærk, at du også kan bruge Salesforce Lightning Inspector, en kromudvidelse, til specifikt at teste Salesforce Lightning. Apex er en Force.com platform proprietært programmeringssprog, der har store ligheder med Java. Det er et objektorienteret, store og små bogstaver, stærkt typer programmeringssprog, der følger krøllede parenteser og punktnotationssyntaks. Du kan bruge Apex til at udføre programmerede funktioner under de fleste Force.com-processer, herunder brugerdefinerede links og knapper, opdateringer, sletninger og optagelse af indsætningshændelseshåndterere gennem Visualforce-side tilpassede controllere eller planlægning.
  • Brug konventionelle navngivningskonventioner - Korrekt navngivning af dine testmetoder, før du begynder at skrive tests, er meget vigtig. Testmetodens navn skal have tre dele. Disse er nameOfMethod (navnet på den individuelle metode, du tester, f.eks. Indsæt / opdater / slet / genopretter, når du tester en trigger, oplysninger om TestPath, som er fleksibel, såsom nulkontakt, hvis du tester, at kontakten er nul, og gyldig, når du tester en positiv / negativ sti.
  • Sørg for 100% dækning - Selvom det almindelige Salesforce-direktiv er, at enhedstest skal have en dækning på 75% af din kode (minus testklasser, opkald til System.debug og testmetoder), og du ikke kan implementere Apex-kode eller pakke AppExchange-apps, skal du bemærk, at dette kun er en standard, og dit mål skal være 100% dækning. Test alle positive / negative tilfælde og for data, der er til stede og ikke er til stede. Andre vigtige tip, når det kommer til kodedækning, er:
    • Du skal køre tests for at opdatere kodedækningsnumre, da disse tal ikke opdateres, når Apex-koden opdateres, indtil testene køres igen.
    • Hvis der har været en opdatering i organisationen siden sidste testkørsel, er der en risiko for, at kodedækningsnumrene er forkerte. Kør testene for det rigtige skøn.
    • Kodedækningsprocenten inkluderer ikke kodedækning fra testede administrerede pakker, med den eneste undtagelse, når disse tests får triggere til at affyre.
    • Dækningen afhænger af det samlede antal kodelinjer. Hvis du tilføjer eller sletter kodelinjer, påvirker du procentdelen.
  • Test sager i klasser og controllere - I Salesforce-udvikling opretter de fleste udviklere separate klasser og controller-filer til hver funktion. Dette gøres for at gøre kodning mere organiseret, lettere, genanvendelig og bærbar. Du skal dog bemærke, at selvom dette er lettere, er det ikke mere effektivt. Du opnår bærbarhed, hvis testkoden er i den originale klasse og selve controller-koden, da du ikke går glip af nogen testklasse, når du migrerer fra sandkasse til produktion.
  • Brug System.assert () - I Apex, System.assert() bruges til at kontrollere forholdene. Dette er en vigtig funktionalitet, da det giver dig mulighed for at bestemme, om en bestemt funktion er udført ved metoden som forventet. Du skal bruge System.assertEquals () og System.assertNotEquals () mellem vigtige funktioner hjælper dig ikke kun med at afgøre, om koden er udført, som den skal, men også for at sikre, at der ikke skrives data fejlagtigt, hvis koden går galt.
  • Omfattende test - Testning skal dække alt. Du skal udføre funktionel test, belastningstest, sikkerhedstest og implementeringstest.
  • Enhedstest - Du skal have enhedstest for at kontrollere, at individuelle poster giver det korrekte og forventede resultat. Mens du bruger en gigantisk test, der dækker hele koden, kan det virke som en god idé, skal du være opmærksom på, at de genererede resultater vil være sværere at debugge, og at svigt vil være sværere at forstå. En enhedstest skal dække en lille delmængde af den funktionalitet, der testes.
  • Test bulk sager - En god testkode (trigger, undtagelse eller klasse) kan være involveret i op til flere hundrede poster (200 for Apex). Du bør drage fordel af dette og teste ikke kun individuelle poster, men også bulk-sager.
  • Positive tests - Test for at sikre, om den forventede adfærd opstår gennem al forventet permutation. Testen skal kontrollere, at brugeren korrekt udfyldte formularen, og at han / hun ikke gik over grænserne.
  • Negative tests - Test de negative tilfælde for at sikre, at fejlmeddelelser produceres korrekt. Eksempler på sådanne negative tilfælde er ikke at kunne specificere negative beløb og ikke være i stand til at tilføje fremtidige datoer. Negative tests er vigtige, fordi korrekt håndtering, når tingene går sydpå, kan gøre hele forskellen.
  • Automatiser test - Traditionelt var Salesforce-test manuel. Du bør overveje automatiseret test, da dette giver flere fordele. Disse inkluderer:
    • Manuel test gør dig modtagelig for fejl, da test er af mennesker og ikke af robotter. Robotter udmærker sig ved gentagne aktiviteter, mens mennesker laver fejl på grund af kedsomhed, nedsat koncentration og konsistens og en tendens til at skære hjørner.
    • Manuel test er gentagne, formel og trættende. Testteamet har det bedre at udføre arbejde, der er mere udforskende.
  • Udfør hver kodelogikfilial - Når du bruger betinget logik (når du har inkluderet ternære operatorer), skal hver gren af ​​kodelogikken udføres.
  • Brug ugyldige og gyldige indgange til opkald til metoder - Opkald til metoder skal foretages ved hjælp af både ugyldige og gyldige input.
  • Gennemfør tests - Sørg for, at testene gennemføres med succes - de bør ikke gennem nogen undtagelser, medmindre fejlene forventes. Håndter alle undtagelser, der er fanget - det er ikke godt nok at fange dem.
  • Brug ORDER BY Keywords - For at sikre, at dine poster returneres i den rækkefølge, du forventer dem, skal du bruge ORDER BY-nøgleordene.
  • Antag ikke, at post-id'er arrangeres fortløbende - Undgå den almindelige fejl at antage, at post-ID'er er arrangeret i rækkefølge. ID'erne er ikke i stigende rækkefølge, medmindre du har indsat flere poster med samme anmodning.
  • Ring til Test.startTest () og Test.stopTest () - Når du kører en Apex-enhedstest, får du mere end 75% kodedækning, der er obligatorisk i Salesforce. Du skal ringe til stopTest før påstande for at tvinge asynkrone koder, der stadig kører, til at afslutte. Kør nye forespørgsler for at få de endelige resultater, da anden kode kan ændre data. Brug af Test.startTest () og Test.stopTest () sikrer, at du sandkasser testen inden for dens guvernørgrænser. På denne måde vil den opsætningskode, du bruger, ikke forstyrre og give dig falske negativer eller positive ting omkring guvernørens grænser. Test.stopTest () sikrer også, at @future-opkald gennemføres til test.
  • Læsbarhed - Læsbarhed er meget vigtig i enhedstest. Testnavne skal indeholde den specifikke handling, der skal foretages, og det forventede resultat. Metoden skal være beskrivende og kort. Metoden skal være sådan, at den kan genbruges på tværs af forskellige tests.
  • Byg store testdatasæt inden startTest - Da dine tests kører i forskellige sandkasse- og produktionsmiljøer, skal du oprette store testdatasæt, før du ringer til startTest for at sikre, at testen har fulde eksekveringsgrænser. Som standard, Salesforce Github kører tests isoleret fra produktionsdata. Når du har brug for systemdata såsom en profil, så spørg for at få den rigtige ting til det specifikke miljø.
  • Generer dine egne testdata - De testdata, du bruger, skal genereres i testen. Du kan generere disse data ved hjælp af @testSetup-kommentar og en TestUtils-klasse for ikke kun at sikre, at du har de rigtige data, men også for at sikre, at alle testene køres på en udvikler-sandkasse uden krav til data.
  • Undgå no-op AKA null operationer - Mange testere bruger no-op AKA null-operationer. Dette er ubrugelige koder, der ikke gør noget. Da de allerede er i din kodebase, vil de føje til din dækningsprocent.
  • Parallel testudførelse - Når du starter test fra Salesforce-brugergrænsefladen eller Developer Console, køres testene parallelt. Dette er en vigtig funktion, da det fremskynder testkørselstiden. Du skal dog bemærke, at dette kan føre til problemer med datakonflikt, og hvis du har mistanke om, at dette kan ske, skal du slå parallel udførelse fra. De mest almindelige årsager til problemer med datakonflikt, der ofte fører til UNABLE_TO_LOCK_ROW fejl er:
    • Når test er beregnet til at opdatere de samme poster på samme tid. Opdatering af de samme poster sker normalt, når test ikke opretter deres egne data.
    • Når der er en blokering af tests, der kører parallelt, og de prøver at oprette poster, der har matchende indeksfeltværdier. En deadlock vil opstå, når to kørende tests har stået i kø for at rulle data tilbage (dette sker, når 2 tester input-poster, der har de samme unikke indeksfeltværdier i forskellige ordrer).
    • For at deaktivere parallel testudførelse skal du gå til Setup, åbne Apex Test, gå til dialogboksen Apex Test Execution Options, vælge Disable Parallel Apex Testing, klikke på OK.

Deaktiver parallel Apex-test

Ansæt en professionel til jobbet, da han får den nødvendige erfaring og uddannelse til at lave en god test, hvilket også giver dig ro i sindet. Ansættelse af en professionel giver dig mulighed for at koncentrere dig om din kerneforretning. Det sparer dig også penge, da du ikke har brug for et internt team til jobbet.

Hvad mener du?

Dette websted bruger Akismet til at reducere spam. Lær, hvordan dine kommentardata behandles.