Consells i pràctiques recomanades per provar integracions de Salesforce

integració de salesforce

Les proves de Salesforce us ajudaran a validar la vostra personalització Integracions de Salesforce i funcionalitats amb altres aplicacions empresarials. Una bona prova cobreix tots els mòduls de Salesforce, des de comptes a clients potencials, d’oportunitats a informes i de campanyes a contactes. Com passa amb totes les proves, hi ha una bona manera (eficaç i eficient) de fer una prova de Salesforce i una mala manera. Llavors, què és la prova de bones pràctiques de Salesforce?

  • Utilitzeu les eines de prova adequades - Les proves de Salesforce es fan al navegador o en un entorn basat en eclipsis. Tant els navegadors més recents com Eclipse tenen excel·lents eines de depuració i podeu combinar-les amb classes de prova per obtenir resultats molt útils. Tot i això, si en necessiteu més, s’hauria d’utilitzar el depurador interactiu Apex (o simplement Apex) de Force.com. Tingueu en compte que també podeu utilitzar Salesforce Lightning Inspector, una extensió cromada, per provar específicament Salesforce Lightning. Apex és un Force.com llenguatge de programació propietari de la plataforma que té grans similituds amb Java. És un llenguatge de programació orientat a objectes, que no distingeix entre majúscules i minúscules, que segueix una sintaxi de notació de punts entre parèntesis i arrissats. Podeu utilitzar Apex per executar funcions programades durant la majoria dels processos de Force.com, inclosos enllaços i botons personalitzats, actualitzacions, supressions i gestors d’esdeveniments d’inserció de registres mitjançant controladors personalitzats de la pàgina de Visualforce o programació.
  • Utilitzar els convenis de denominació adequats: És molt important posar un nom adequat als mètodes de prova abans de començar a escriure proves. El nom del mètode de prova hauria de tenir tres parts. Aquests són nameOfMethod (nom del mètode individual que esteu provant, com ara inserir / actualitzar / eliminar / recuperar quan es provoca un activador, informació sobre TestPath que és flexible, com ara el contacte nul si esteu provant que el contacte és nul i és vàlid quan es prova) un camí positiu / negatiu.
  • Assegureu-vos un 100% de cobertura: Tot i que la directiva estàndard de Salesforce és que la prova unitària hauria de tenir una cobertura del 75% del vostre codi (menys classes de proves, trucades a System.debug i mètodes de prova) i no podreu desplegar codi Apex ni empaquetar aplicacions AppExchange, tingueu en compte que això és només un estàndard i que el vostre objectiu hauria de ser un 100% de cobertura. Proveu tots els casos positius / negatius i si hi ha dades presents i no presents. Altres consells importants a l’hora de cobrir el codi són:
    • Heu d'executar proves per actualitzar els números de cobertura del codi, ja que aquests números no s'actualitzen quan s'actualitza el codi Apex fins que es tornen a executar.
    • Si hi ha hagut una actualització a l’organització des de l’última prova, hi ha el risc que els números de cobertura de codi siguin incorrectes. Torneu a executar les proves per obtenir l’estimació correcta.
    • El percentatge de cobertura de codi no inclou la cobertura de codi de les proves de paquets gestionats, amb l'única excepció quan aquestes proves provoquen l'activació dels activadors.
    • La cobertura depèn del nombre total de línies de codi. Si afegiu o suprimiu línies de codi, afectareu el percentatge.
  • Casos de prova en classes i controladors - Al desenvolupament de Salesforce, la majoria dels desenvolupadors creen classes i fitxers de controlador diferents per a cada funció. Això es fa perquè la codificació sigui més organitzada, fàcil, reutilitzable i portàtil. Tanmateix, heu de tenir en compte que, tot i que això és més fàcil, no és més eficient. Aconseguirà la portabilitat si el codi de prova es troba a la classe original i al codi del controlador en si mateix, ja que no es perdrà cap classe de prova en migrar de sandbox a producció.
  • Utilitzeu System.assert () - A Apex, System.assert() s'utilitza per comprovar les condicions. Aquesta és una funcionalitat important, ja que us permet determinar si el mètode ha realitzat una funció concreta com s’esperava. Haureu d’utilitzar System.assertEquals () i System.assertNotEquals () entre les funcionalitats crítiques no només us ajudarà a determinar si el codi s’ha executat com hauria de fer-ho, sinó també a assegurar-vos que no s’escriuen dades erròniament si el codi surt malament.
  • Prova integral - Les proves haurien de cobrir tot. Heu de fer proves funcionals, proves de càrrega, proves de seguretat i proves de desplegament.
  • Proves d'unitat - Hauríeu de fer proves unitàries per verificar que els registres individuals produeixen el resultat correcte i esperat. Tot i que fer servir una prova gegant que cobreixi tot el codi pot semblar una bona idea, tingueu en compte que els resultats generats seran més difícils de depurar i que l’error serà més difícil d’entendre. Una prova unitària hauria de cobrir un petit subconjunt de la funcionalitat que s'està provant.
  • Casos massius de prova: Es pot implicar un bon codi de prova (activador, excepció o classe) fins a diversos centenars de registres (200 per a Apex). Haureu d'aprofitar-ho i provar no només registres individuals, sinó també casos massius.
  • Proves positives - Proveu per assegurar-vos si el comportament esperat es produeix mitjançant tota la permutació esperada. La prova hauria de verificar que l'usuari hagi emplenat correctament el formulari i que no hagi superat els límits.
  • Proves negatives: Proveu els casos negatius per assegurar-vos que els missatges d'error es produeixen correctament. Exemples d’aquests casos negatius no són la possibilitat d’especificar quantitats negatives ni la possibilitat d’afegir dates futures. Les proves negatives són importants perquè el maneig correcte quan les coses van cap al sud pot marcar la diferència.
  • Proves automatitzades: Tradicionalment, les proves de Salesforce eren manuals. Heu de tenir en compte les proves automatitzades, ja que ofereixen més avantatges. Això inclou:
    • Les proves manuals us fan susceptibles a errors, ja que les proves són realitzades per humans i no per robots. Els robots sobresurten en activitats repetitives mentre els humans cometen errors a causa de l’avorriment, la concentració i la consistència reduïdes i la tendència a tallar cantonades.
    • Les proves manuals són repetitives, fórmules i cansades. L’equip de proves és millor que faci treballs més exploratoris.
  • Executeu cada branca de la lògica del codi: Quan s'utilitza la lògica condicional (quan ha inclòs operadors ternaris), s'ha d'executar cada branca de la lògica del codi.
  • Utilitzeu entrades vàlides i no vàlides per a trucades a mètodes: Les trucades a mètodes s’han de fer mitjançant entrades vàlides i no vàlides.
  • Proves completes - Assegureu-vos que les proves es completen correctament; no haurien de fer cap excepció tret que s’esperin els errors. Gestioneu totes les excepcions capturades: no és suficient per agafar-les.
  • Utilitza ORDER BY Keywords: Per assegurar-vos que els vostres registres es retornen en l'ordre que espereu, utilitzeu les paraules clau ORDRE PER.
  • No assumeixi que els identificadors de registre es disposen de manera seqüencial: Eviteu l'error comú de suposar que els identificadors de registre es disposen en ordre seqüencial. Els identificadors no estan en ordre ascendent, tret que hàgiu inserit diversos registres amb la mateixa sol·licitud.
  • Truqueu a Test.startTest () i Test.stopTest () - Quan feu una prova d’unitat Apex, obtindreu més del 75% de cobertura de codi obligatòria a Salesforce. Cal trucar a stopTest abans de les afirmacions per forçar els codis asíncrons que encara es poden executar. Executeu consultes noves per obtenir resultats finals, ja que altres codis poden canviar les dades. UseTest.startTest () i Test.stopTest () us garanteix que proveu la prova dins dels seus límits de governador. D'aquesta manera, el codi de configuració que utilitzeu no interferirà i us donarà falsos negatius o positius que envolten els límits del governador. Test.stopTest () també garanteix que les trucades @future es completin per provar-les.
  • Legibilitat - La llegibilitat és molt important en les proves unitàries. Els noms de les proves haurien d’incloure l’acció específica que cal dur a terme i el resultat esperat. El mètode ha de ser descriptiu i breu. El mètode ha de ser tal que pugui ser reutilitzable en diferents proves.
  • Creeu grans conjunts de dades de prova abans de startTest - Atès que les vostres proves s’executaran en diferents entorns de producció i sandbox, creeu grans conjunts de dades de proves abans de trucar a startTest per assegurar-vos que la prova tingui límits d’execució complets. Per defecte, Salesforce Github executa proves aïllades de les dades de producció. Quan necessiteu dades del sistema, com ara un perfil, feu una consulta per obtenir el correcte per a aquest entorn específic.
  • Genereu les vostres pròpies dades de prova: Les dades de prova que utilitzeu s'han de generar a la prova. Podeu generar aquestes dades mitjançant l’anotació @testSetup i una classe TestUtils, no només per assegurar-vos que teniu les dades adequades, sinó també per assegurar-vos que totes les proves s’executen en una caixa de proves del desenvolupador sense requisits de dades.
  • Eviteu les operacions nul·les AKA sense operacions - Molts provadors utilitzen operacions nul·les AKA sense operacions. Són codis inútils que no fan res. Com que ja són a la base de codis, s'afegiran al percentatge de cobertura.
  • Execució de proves paral·leles: Quan inicieu proves des de la interfície d'usuari de Salesforce o des de la Consola per a desenvolupadors, les proves s'executaran en paral·lel. Aquesta és una característica important ja que accelera el temps d'execució de la prova. Tanmateix, heu de tenir en compte que això pot provocar problemes de contenció de dades i, si sospiteu que això pot passar, desactiveu l'execució paral·lela. Les causes més freqüents de problemes de contenció de dades que solen provocar errors UNABLE_TO_LOCK_ROW són:
    • Quan les proves estan destinades a actualitzar els mateixos registres al mateix temps. L’actualització dels mateixos registres sol passar quan les proves no creen les seves pròpies dades.
    • Quan hi ha un punt mort a les proves que s’executen en paral·lel i intenten crear registres que tinguin valors de camp d’índex coincidents. Es produirà un bloqueig quan hi hagi dues cues en execució per fer retrocedir les dades (això es produeix quan 2 proves registres d'entrada que tenen els mateixos valors de camp d'índex únics en diferents ordres).
    • Per desactivar l'execució de la prova paral·lela, aneu a Configuració, introduïu la prova Apex, aneu al quadre de diàleg Opcions d'execució de la prova Apex, seleccioneu Desactiva la prova paral·lela de l'apex i feu clic a D'acord

Desactiveu la prova paral·lela d'apex

Contracteu un professional per la feina, ja que tindrà l’experiència i la formació necessàries per fer una bona prova, cosa que també us proporcionarà tranquil·litat. Contractar un professional us permet concentrar-vos en el vostre negoci principal. També us estalvia diners, ja que no necessiteu un equip intern per a la feina.

Què et sembla?

Aquest lloc utilitza Akismet per reduir el correu no desitjat. Esbrineu com es processa el vostre comentari.