Συμβουλές και βέλτιστες πρακτικές για τον έλεγχο των ενοποιήσεων του Salesforce

ολοκλήρωση του salesforce

Η δοκιμή Salesforce θα σας βοηθήσει να επικυρώσετε τις προσαρμοσμένες σας ρυθμίσεις Ενσωματώσεις Salesforce και λειτουργίες με άλλες εταιρικές εφαρμογές. Μια καλή δοκιμή καλύπτει όλες τις λειτουργικές μονάδες Salesforce από λογαριασμούς σε δυνητικούς πελάτες, από ευκαιρίες έως αναφορές και από καμπάνιες έως επαφές. Όπως συμβαίνει με όλες τις δοκιμές, υπάρχει ένας καλός (αποτελεσματικός και αποδοτικός) τρόπος για να κάνετε μια δοκιμή Salesforce και ένας κακός τρόπος. Λοιπόν, τι δοκιμάζει η Salesforce καλή πρακτική;

  • Χρησιμοποιήστε τα σωστά εργαλεία δοκιμών - Ο έλεγχος Salesforce πραγματοποιείται στο πρόγραμμα περιήγησης ή σε περιβάλλον που βασίζεται σε έκλειψη. Τόσο τα πιο πρόσφατα προγράμματα περιήγησης όσο και η έκλειψη έχουν εξαιρετικά εργαλεία εντοπισμού σφαλμάτων και μπορείτε να τα συνδυάσετε με δοκιμαστικά μαθήματα για πολύ χρήσιμα αποτελέσματα. Ωστόσο, εάν χρειάζεστε περισσότερα, θα πρέπει να χρησιμοποιείται το Apex Interactive Debugger (ή απλά Apex) από το Force.com. Σημειώστε ότι μπορείτε επίσης να χρησιμοποιήσετε το Salesforce Lightning Inspector, μια επέκταση χρωμίου, για να δοκιμάσετε συγκεκριμένα το Salesforce Lightning. Η κορυφή είναι ένα Force.com αποκλειστική γλώσσα προγραμματισμού πλατφόρμας που έχει μεγάλες ομοιότητες με την Java. Πρόκειται για αντικειμενοστρεφή, χωρίς διάκριση πεζών-κεφαλαίων, έντονα τύπους γλώσσας προγραμματισμού που ακολουθεί σγουρά αγκύλες και σύνταξη κουκίδων. Μπορείτε να χρησιμοποιήσετε το Apex για να εκτελέσετε προγραμματισμένες λειτουργίες κατά τη διάρκεια των περισσότερων διαδικασιών Force.com, συμπεριλαμβανομένων προσαρμοσμένων συνδέσμων και κουμπιών, ενημερώσεων, διαγραφών και χειριστών συμβάντων εισαγωγής εγγραφών μέσω προσαρμοσμένων ελεγκτών ή προγραμματισμού της σελίδας Visualforce.
  • Χρησιμοποιήστε τις κατάλληλες συμβάσεις ονομασίας - Η σωστή ονομασία των μεθόδων δοκιμής πριν ξεκινήσετε να γράφετε δοκιμές είναι πολύ σημαντική. Το όνομα της μεθόδου δοκιμής πρέπει να έχει τρία μέρη. Αυτά είναι nameOfMethod (όνομα της μεμονωμένης μεθόδου που δοκιμάζετε, όπως εισαγωγή / ενημέρωση / διαγραφή / κατάργηση διαγραφής κατά τη δοκιμή ενός κανόνα ετικέτας, πληροφορίες σχετικά με το TestPath που είναι ευέλικτο, όπως μηδενική επαφή, εάν ελέγχετε ότι η επαφή είναι μηδενική και έγκυρη κατά τη δοκιμή μια θετική / αρνητική πορεία.
  • Εξασφάλιση κάλυψης 100% - Παρόλο που η τυπική οδηγία Salesforce είναι ότι η δοκιμή μονάδας θα πρέπει να καλύπτει το 75% του κωδικού σας (μείον τις τάξεις δοκιμής, τις κλήσεις στο System.debug και τις μεθόδους δοκιμής) και δεν θα μπορείτε να αναπτύξετε κώδικα Apex ή πακέτο εφαρμογών AppExchange, θα πρέπει Σημειώστε ότι αυτό είναι απλώς ένα πρότυπο και ο στόχος σας πρέπει να είναι 100% κάλυψη. Ελέγξτε όλες τις θετικές / αρνητικές περιπτώσεις και για δεδομένα που υπάρχουν και δεν υπάρχουν. Άλλες σημαντικές συμβουλές όσον αφορά την κάλυψη κώδικα είναι:
    • Θα πρέπει να εκτελέσετε δοκιμές για να ανανεώσετε τους αριθμούς κάλυψης κώδικα, καθώς αυτοί οι αριθμοί δεν ανανεώνονται όταν ενημερώνεται ο κωδικός Apex έως ότου εκτελεστούν ξανά οι δοκιμές.
    • Εάν υπάρχει μια ενημέρωση στον οργανισμό από την τελευταία δοκιμαστική εκτέλεση, υπάρχει ο κίνδυνος οι αριθμοί κάλυψης κώδικα να είναι λανθασμένοι. Εκτελέστε ξανά τις δοκιμές για τη σωστή εκτίμηση.
    • Το ποσοστό κάλυψης κώδικα δεν περιλαμβάνει κάλυψη κώδικα από δοκιμές διαχειριζόμενων πακέτων, με μόνη εξαίρεση όταν αυτές οι δοκιμές προκαλούν την ενεργοποίηση των σκανδάλης.
    • Η κάλυψη εξαρτάται από τον συνολικό αριθμό γραμμών κώδικα. Εάν προσθέσετε ή διαγράψετε γραμμές κώδικα, θα επηρεάσετε το ποσοστό.
  • Θήκες δοκιμής σε τάξεις και ελεγκτές - Στην ανάπτυξη του Salesforce, οι περισσότεροι προγραμματιστές δημιουργούν ξεχωριστές τάξεις και αρχεία ελεγκτή για κάθε λειτουργία. Αυτό γίνεται για να κάνει την κωδικοποίηση πιο οργανωμένη, ευκολότερη, επαναχρησιμοποιήσιμη και φορητή. Θα πρέπει, ωστόσο, να σημειώσετε ότι ενώ αυτό είναι ευκολότερο, δεν είναι πιο αποτελεσματικό. Θα επιτύχετε φορητότητα εάν ο κωδικός δοκιμής είναι στην αρχική τάξη και ο ίδιος ο κωδικός ελεγκτή, καθώς δεν θα χάσετε καμία δοκιμαστική κλάση κατά τη μετάβαση από το sandbox στην παραγωγή.
  • Χρησιμοποιήστε το System.assert () - Στο Apex, System.assert() χρησιμοποιείται για τον έλεγχο των συνθηκών. Αυτή είναι μια σημαντική λειτουργικότητα δεδομένου ότι σας επιτρέπει να προσδιορίσετε εάν μια συγκεκριμένη λειτουργία έχει εκτελεστεί με τη μέθοδο όπως αναμενόταν. Θα πρέπει να χρησιμοποιήσετε το System.assertEquals () και το System.assertNotEquals () μεταξύ κρίσιμων λειτουργιών όχι μόνο σας βοηθά να προσδιορίσετε εάν ο κώδικας έχει εκτελεστεί όπως θα έπρεπε, αλλά και να διασφαλίσετε ότι δεν γράφονται δεδομένα λανθασμένα εάν ο κώδικας πάει στραβά.
  • Περιεκτική δοκιμή - Οι δοκιμές πρέπει να καλύπτουν τα πάντα. Θα πρέπει να κάνετε λειτουργικές δοκιμές, δοκιμές φορτίου, δοκιμές ασφαλείας και δοκιμές ανάπτυξης.
  • Δοκιμές μονάδας - Θα πρέπει να έχετε δοκιμές μονάδας για να επαληθεύσετε ότι μεμονωμένες εγγραφές παράγουν το σωστό και αναμενόμενο αποτέλεσμα. Ενώ χρησιμοποιείτε μια τεράστια δοκιμή που καλύπτει ολόκληρο τον κώδικα μπορεί να φαίνεται καλή ιδέα, σημειώστε ότι τα αποτελέσματα που δημιουργούνται θα είναι πιο δύσκολο να εντοπιστούν και ότι η αποτυχία θα είναι πιο δύσκολο να κατανοηθεί. Ένα τεστ μονάδας πρέπει να καλύπτει ένα μικρό υποσύνολο της λειτουργικότητας που δοκιμάζεται.
  • Μαζικές δοκιμές - Ένας καλός κωδικός δοκιμής (σκανδάλη, εξαίρεση ή κλάση) μπορεί να περιληφθεί για έως και αρκετές εκατοντάδες εγγραφές (200 για Apex). Θα πρέπει να επωφεληθείτε από αυτό και να δοκιμάσετε όχι μόνο μεμονωμένες εγγραφές, αλλά και μαζικές περιπτώσεις.
  • Θετικές δοκιμές - Ελέγξτε για να βεβαιωθείτε ότι η αναμενόμενη συμπεριφορά εμφανίζεται μέσω όλων των αναμενόμενων παραλλαγών Η δοκιμή πρέπει να επαληθεύσει ότι ο χρήστης συμπλήρωσε σωστά τη φόρμα και ότι δεν ξεπέρασε τα όρια.
  • Αρνητικές δοκιμές - Ελέγξτε τις αρνητικές περιπτώσεις για να βεβαιωθείτε ότι τα μηνύματα σφάλματος παράγονται σωστά. Παραδείγματα τέτοιων αρνητικών περιπτώσεων δεν είναι σε θέση να προσδιορίσουν αρνητικά ποσά και δεν είναι σε θέση να προσθέσουν μελλοντικές ημερομηνίες. Οι αρνητικές δοκιμές είναι σημαντικές επειδή ο σωστός χειρισμός όταν τα πράγματα πηγαίνουν νότια μπορούν να κάνουν τη διαφορά.
  • Αυτοματοποίηση δοκιμών - Παραδοσιακά, οι δοκιμές Salesforce ήταν χειροκίνητες. Θα πρέπει να εξετάσετε τις αυτοματοποιημένες δοκιμές καθώς αυτό προσφέρει περισσότερα πλεονεκτήματα. Αυτά περιλαμβάνουν:
    • Η μη αυτόματη δοκιμή σάς κάνει ευαίσθητους σε λάθη, καθώς η δοκιμή γίνεται από ανθρώπους και όχι από ρομπότ. Τα ρομπότ υπερέχουν σε επαναλαμβανόμενες δραστηριότητες, ενώ οι άνθρωποι κάνουν λάθη λόγω της πλήξης, της μειωμένης συγκέντρωσης και της συνέπειας και της τάσης να κόβουν τις γωνίες.
    • Η μη αυτόματη δοκιμή είναι επαναλαμβανόμενη, τυπική και κουραστική. Η ομάδα δοκιμών είναι καλύτερα να κάνει δουλειά που είναι πιο διερευνητική.
  • Εκτελέστε κάθε κλάδο λογικής κώδικα - Όταν χρησιμοποιείτε λογική υπό όρους (όταν έχετε συμπεριλάβει τριμερείς τελεστές), κάθε κλάδος της λογικής κώδικα πρέπει να εκτελείται.
  • Χρήση μη έγκυρων και έγκυρων εισόδων για κλήσεις σε μεθόδους - Οι κλήσεις προς μεθόδους πρέπει να πραγματοποιούνται χρησιμοποιώντας μη έγκυρες και έγκυρες εισόδους.
  • Πλήρεις δοκιμές - Βεβαιωθείτε ότι οι δοκιμές ολοκληρώθηκαν με επιτυχία - δεν θα πρέπει να περάσουν εξαιρέσεις, εκτός εάν αναμένονται τα λάθη. Αντιμετωπίστε όλες τις εξαιρέσεις που πιάστηκαν - η σύλληψή τους δεν είναι αρκετά καλή.
  • Χρήση ORDER BY Λέξεις-κλειδιά - Για να βεβαιωθείτε ότι τα αρχεία σας επιστρέφονται με τη σειρά που τα περιμένετε, χρησιμοποιήστε τις λέξεις-κλειδιά ORDER BY.
  • Μην υποθέσετε ότι τα αναγνωριστικά εγγραφής τακτοποιούνται διαδοχικά - Αποφύγετε το συνηθισμένο λάθος να υποθέσετε ότι τα αναγνωριστικά εγγραφής είναι διαδοχικά. Τα αναγνωριστικά δεν είναι σε αύξουσα σειρά, εκτός εάν έχετε εισαγάγει πολλές εγγραφές με το ίδιο αίτημα.
  • Καλέστε Test.startTest () και Test.stopTest () - Όταν εκτελείτε μια δοκιμή μονάδας Apex, θα λάβετε περισσότερο από το 75% κάλυψη κώδικα που είναι υποχρεωτικό στο Salesforce. Θα πρέπει να καλέσετε το stopTest πριν από τους ισχυρισμούς για να επιβάλλετε ασύγχρονους κωδικούς που ενδέχεται να εξακολουθούν να εκτελούνται για να ολοκληρωθεί. Εκτελέστε νέα ερωτήματα για τελικά αποτελέσματα, καθώς άλλος κώδικας ενδέχεται να αλλάξει δεδομένα. Χρησιμοποιώντας τοTest.startTest () και το Test.stopTest () διασφαλίζετε ότι θα δοκιμάσετε το τεστ εντός των ορίων του κυβερνήτη. Με αυτόν τον τρόπο, ο κωδικός ρύθμισης που χρησιμοποιείτε δεν θα παρεμποδίσει και θα σας δώσει ψευδώς αρνητικά ή θετικά γύρω από τα όρια του κυβερνήτη. Το Test.stopTest () διασφαλίζει επίσης ότι οι κλήσεις @future θα ολοκληρωθούν για δοκιμή.
  • Αναγνωσιμότητα - Η αναγνωσιμότητα είναι πολύ σημαντική στις δοκιμές μονάδας. Τα ονόματα των δοκιμών πρέπει να περιλαμβάνουν τη συγκεκριμένη ενέργεια που πρέπει να αναληφθεί και το αναμενόμενο αποτέλεσμα. Η μέθοδος πρέπει να είναι περιγραφική και σύντομη. Η μέθοδος πρέπει να είναι τέτοια ώστε να μπορεί να επαναχρησιμοποιηθεί σε διαφορετικές δοκιμές.
  • Δημιουργήστε μεγάλα σύνολα δεδομένων δοκιμής πριν από την έναρξη δοκιμής - Δεδομένου ότι οι δοκιμές σας θα εκτελούνται σε διαφορετικά περιβάλλοντα άμμου και παραγωγής, δημιουργήστε μεγάλα σύνολα δεδομένων δοκιμής πριν καλέσετε το startTest για να βεβαιωθείτε ότι η δοκιμή έχει πλήρη όρια εκτέλεσης. Από προεπιλογή, Salesforce Github εκτελεί δοκιμές απομονωμένες από δεδομένα παραγωγής. Όταν χρειάζεστε δεδομένα συστήματος, όπως προφίλ, κάντε ερώτημα για να λάβετε το σωστό για αυτό το συγκεκριμένο περιβάλλον.
  • Δημιουργήστε τα δικά σας δεδομένα δοκιμής - Τα δεδομένα δοκιμής που χρησιμοποιείτε πρέπει να δημιουργηθούν στη δοκιμή. Μπορείτε να δημιουργήσετε αυτά τα δεδομένα χρησιμοποιώντας τον σχολιασμό @testSetup και μια κλάση TestUtils, όχι μόνο για να βεβαιωθείτε ότι έχετε τα σωστά δεδομένα, αλλά και για να διασφαλίσετε ότι όλες οι δοκιμές εκτελούνται σε περιβάλλον δοκιμών προγραμματιστή χωρίς απαίτηση για δεδομένα.
  • Αποφύγετε τις μηδενικές λειτουργίες AKA - Πολλοί δοκιμαστές χρησιμοποιούν μηδενικές λειτουργίες AKA. Αυτοί είναι άχρηστοι κωδικοί που δεν κάνουν τίποτα. Δεδομένου ότι βρίσκονται ήδη στη βάση κώδικα, θα προσθέσουν στο ποσοστό κάλυψης.
  • Εκτέλεση παράλληλης δοκιμής - Όταν ξεκινάτε δοκιμές από το περιβάλλον εργασίας χρήστη Salesforce ή από το Developer Console, οι δοκιμές θα εκτελούνται παράλληλα. Αυτό είναι ένα σημαντικό χαρακτηριστικό καθώς επιταχύνει το χρόνο δοκιμής. Θα πρέπει, ωστόσο, να σημειώσετε ότι αυτό μπορεί να οδηγήσει σε προβλήματα διαφωνίας δεδομένων και εάν υποψιάζεστε ότι αυτό μπορεί να συμβεί, απενεργοποιήστε την παράλληλη εκτέλεση. Οι πιο συνηθισμένες αιτίες ζητημάτων διαφωνίας δεδομένων που συχνά οδηγούν σε σφάλματα UNABLE_TO_LOCK_ROW είναι:
    • Όταν οι δοκιμές προορίζονται να ενημερώσουν τα ίδια αρχεία ταυτόχρονα. Η ενημέρωση των ίδιων εγγραφών συμβαίνει συνήθως όταν οι δοκιμές δεν δημιουργούν τα δικά τους δεδομένα.
    • Όταν υπάρχει αδιέξοδο στις δοκιμές που εκτελούνται παράλληλα και προσπαθούν να δημιουργήσουν εγγραφές που έχουν αντίστοιχες τιμές πεδίου ευρετηρίου. Ένα αδιέξοδο θα συμβεί όταν 2 δοκιμές που εκτελούνται στην ουρά για την επαναφορά δεδομένων (αυτό συμβαίνει όταν 2 δοκιμές εισάγουν εγγραφές που έχουν τις ίδιες μοναδικές τιμές πεδίου ευρετηρίου σε διαφορετικές παραγγελίες).
    • Για να απενεργοποιήσετε την εκτέλεση παράλληλης δοκιμής, μεταβείτε στην ενότητα Ρύθμιση, πληκτρολογήστε Apex Test, μεταβείτε στο παράθυρο διαλόγου Επιλογές εκτέλεσης δοκιμής Apex, επιλέξτε Απενεργοποίηση δοκιμής παράλληλης Apex, κάντε κλικ στο OK.

Απενεργοποίηση παράλληλης δοκιμής κορυφής

Προσλάβετε έναν επαγγελματία για τη δουλειά αφού θα έχει την απαραίτητη εμπειρία και εκπαίδευση για να κάνει ένα καλό τεστ, το οποίο σας δίνει επίσης ηρεμία. Η πρόσληψη επαγγελματία σάς επιτρέπει να επικεντρωθείτε στην βασική σας επιχείρηση. Σας εξοικονομεί επίσης χρήματα, καθώς δεν θα χρειαστείτε μια εσωτερική ομάδα για τη δουλειά.

Ποια είναι η γνώμη σας;

Αυτός ο ιστότοπος χρησιμοποιεί το Akismet για να μειώσει το spam. Μάθετε πώς επεξεργάζονται τα δεδομένα των σχολίων σας.