‭Testing, Debugging, and Deployment - PD1‬

‭23 September 2024‬

‭Write and execute tests for triggers, controllers, classes, flows, and‬
‭processes using various sources of test data.‬

‭●‬ ‭Running a Subset of Tests in a Deployment‬

‭○‬ ‭To shorten the deployment time to production, a subset of tests can be run‬
‭when deploying Apex components. When running a subset of tests, code‬
‭coverage is computed for each class and trigger individually and is different‬
‭than the overall coverage percentage.‬
‭○‬ ‭If the deployment package contains Apex classes and triggers, the executed‬
‭tests must cover each class and trigger for a minimum of 75% code coverage.‬
‭○‬ ‭Running a subset of tests can also be run in the Metadata API and is exposed‬
‭in tools that are based on Metadata API, such as Salesforce CLI.‬
‭○‬ ‭Only test classes can be specified, not individual test methods.‬
‭●‬ ‭Run Unit Test Methods‬

‭1‬
 ‭○‬ ‭All tests can be run by selecting ‘Run All’ from the ‘Test’ menu item in the‬
‭Developer Console‬

‭○‬ ‭It is also possible to run all tests by clicking the ‘Run All Tests’ button on the‬
‭‘Apex Classes’ page in Setup.‬

‭2‬
 ‭○‬ ‭Test classes can be run using the Apex Test Execution page in Setup and the‬
‭testing options available in the Developer console‬

‭○‬ ‭Tests can also be executed using Salesforce Extensions for Visual Studio‬
‭Code, Code Builder, and APIs such as the SOAP API and Tooling Rest API.‬
‭○‬ ‭Apex test classes and specific test methods can be executed in the Developer‬
‭Console, Setup, Visual Studio Code, Code Builder, and when using an API‬
‭such as the SOAP API.‬
‭●‬ ‭Skip Code Coverage Information‬
‭○‬ ‭The option to skip code coverage is available when a new test is run in the‬
‭Developer Console by selecting the ‘New Run’ option from the ‘Test’ menu.‬
‭■‬ ‭The ‘Setting’ button can be clicked to specify whether code coverage‬
‭should be skipped.‬

‭3‬
 ‭○‬ ‭It is also possible to select this option on the ‘Apex Test Execution’ page in‬
‭Setup while selecting the test classes for a test run.‬

‭●‬ ‭Test Class‬

‭○‬ ‭getStandardPricebookId()‬
‭■‬ ‭Returns the ID of the standard price book in the organization‬
‭regardless of whether the test can query organization data.‬
‭■‬ ‭Creating price book entries with a standard price required the ID of‬
‭the standard price book.‬
‭■‬ ‭This method is used to get the standard price book ID so that price‬
‭book entries can be created in tests.‬
‭●‬ ‭Loading Test Data‬

‭4‬
 ‭○‬ ‭Test.loadData()‬

‭■‬ ‭Call Test.loadData() within the test method, passion the sObject type‬
‭token and the static resource name as the parameters.‬

‭●‬ ‭Testing Framework‬

‭○‬ ‭The test framework provides a framework to create & run unit test, run only‬
‭the code that is marked as tests, and check the test results and code‬
‭coverage to help ensure that the code can be deployed to production.‬
‭○‬ ‭The Apex testing framework cannot be used to perform security vulnerability‬
‭checks.‬
‭○‬ ‭Unit tests are manually created.‬
‭●‬ ‭Testing Apex‬
‭○‬ ‭Apex test classes cannot send outbound emails nor perform callouts‬
‭○‬ ‭Test classes can perform single and bulk actions‬
‭●‬ ‭Manage Sets of Apex Test Classes with Test Suites‬

‭○‬ ‭The suite manager is used to create or delete test suites or edit which classes‬
‭a particular test suite contains,‬

‭○‬ ‭A test suite is a collection of Apex test classes that are run together. The new‬
‭suite option is used to group test classes that are run together. It cannot be‬
‭used to create a test class.‬

‭●‬ ‭Tests Tab‬

‭5‬
 ‭○‬ ‭The Developer Console runs tests asynchronously by default. Tests are run‬
‭synchronously only when there is only one test class being run and the‬
‭[Always Run Asynchronously] option is not checked.‬

‭○‬ ‭If multiple test classes are run, the test will always be run asynchronously‬
‭whether or not the [Always Run Asynchronously] option is checked.‬
‭●‬ ‭Using Limits, startTest, and stopTest‬
‭○‬ ‭The Test.startTest() and Test.stopTest() methods can be used with the Limits‬
‭methods(Such as Limits.getDMLStatements(), Limits.getQueries(). etc.) to‬
‭determine the amount of governed resources that have been consumed in a‬
‭specific block of code.‬

‭○‬ ‭Test.startTest()‬

‭■‬ ‭Marks the point in the test code when the test actually begins‬

‭○‬ ‭Test.stopTest()‬

‭■‬ ‭Marks the point in the test code when the test ends.‬

‭○‬ ‭Any code that executes after the call to Test.startTest() and before‬
‭Test.stopTest() is assigned a new set of governor limits which will ignore any‬
‭DML or queries done outside of the start and stop testing.‬

‭■‬ ‭It will only count what happens in between as part of the test.‬

‭■‬

‭6‬
 ‭●‬ ‭Error methods for testing Apex code‬

‭○‬ ‭The‬‭sObject class‬‭provides the error methods addError(),‬‭hasErrors(), and‬

‭getErrors() that can be used for testing Apex code.‬

‭○‬ ‭AddError()‬

‭■‬ ‭Can be used to dynamically add errors to fields of a sObject‬

‭associated with the specified field‬

‭○‬ ‭hasErrors()‬

‭■‬ ‭Method returns true if an object instance contains any errors‬

‭○‬ ‭getErrors()‬

‭■‬ ‭Used to retrieve a list of errors(List<Database.Error>) that are added‬

‭to an object instance‬

‭●‬ ‭Using the runAs Method‬

‭○‬ ‭The system method runAs() enables test methods to be written that change‬
‭the user context to an existing user or a new user so that the user’s record‬
‭sharing is enforced.‬

‭○‬ ‭The runAs() method does not enforce user permissions or field-level‬
‭permissions, only record sharing.‬

‭○‬ ‭It can only be used in test methods.‬

‭○‬ ‭The runAs() method ignores user license limits.‬

‭7‬
 ‭○‬ ‭New users can be created with runAs() even if the organization has no‬
‭additional user licenses.‬

‭Describe how to approach debugging system issues and monitoring‬

‭flows, processes, and asynchronous and batch jobs, etc.‬

‭●‬ ‭Track Your Flows’ Usage of Limited Resources‬

‭○‬ ‭Debug logs can track a flow’s usage of limited resources in a transaction.‬
‭○‬ ‭To display this information in the debug logs, the Workflow log level should‬
‭be set to FINER. The Debug Details in Flow Builder can also show governor‬
‭limit consumption information along with variables used, actions performed,‬
‭and results of a flow.‬
‭●‬ ‭Debug Flows More Easily with Consistent Terms and Direct Debugging‬
‭for Schedule-Triggered Flows‬
‭○‬ ‭A Screen Flow report, which is only available for screen flows, shows the‬
‭flows that users started, paused, and finished;‬
‭○‬ ‭It does not display resource usage‬
‭●‬ ‭Log Inspector‬

‭8‬
 ‭○‬ ‭The ‘Executed Units’ tab under the ‘Execution Overview’ log panel provides‬
‭several metrics, including the execution time (total, average, minimum, and‬
‭maximum), for any item that is captured in the debug log.‬
‭○‬ ‭The ‘Stack Tree’ and ‘Execution Stack’ can only display the total execution‬
‭time.‬

‭○‬
‭●‬ ‭Troubleshoot Processes with Apex Debug Logs‬
‭○‬ ‭Record change processes in Process Builder are fired when a record is‬
‭updated that meets the defined criteria.‬
‭○‬ ‭While ‘myVariable_current’ in the debug log contains all of the record’s‬
‭current field values,‬
‭○‬ ‭‘myVariable_old’ contains all the field values before the record was updated.‬
‭○‬ ‭These information can then be used to determine whether the records are‬
‭updated accordingly to meet the criteria required by the processes.‬

‭9‬
 ‭○‬
‭●‬ ‭Debug Log‬
‭○‬ ‭The debug log does not include information from actions triggered by‬
‭time-based workflows.‬
‭○‬ ‭A debug log can record‬
‭■‬ ‭database operations‬
‭■‬ ‭System processes‬
‭■‬ ‭And errors that occur when executing a transaction or Running unit‬
‭tests‬
‭○‬ ‭Debug logs can contain information about‬
‭■‬ ‭Database changes‬
‭■‬ ‭HTTP callouts‬
‭■‬ ‭Apex errors‬
‭■‬ ‭Resources used by Apex‬
‭■‬ ‭Automated workflow processes‬
‭●‬ ‭Workflow rules‬
‭●‬ ‭Assignment rules‬
‭●‬ ‭Approval processes‬
‭●‬ ‭Validation rules‬
‭○‬ ‭Debug log categories‬

‭■‬ ‭Available are as follows:‬

‭●‬ ‭Apex Code,‬

‭10‬
 ‭○‬ ‭Only helpful when apex code is involved.‬

‭●‬ ‭Apex Profiling,‬

‭●‬ ‭Callout,‬

‭●‬ ‭Database,‬

‭○‬ ‭Provide information about what data is being stored in‬

‭the database‬

‭●‬ ‭System,‬

‭●‬ ‭Validation,‬

‭○‬ ‭Provide data about validation rules‬

‭●‬ ‭Visualfoce,‬

‭●‬ ‭Workflow.‬

‭○‬ ‭Events related to‬‭processes‬‭and‬‭Escalation rules‬

‭■‬
‭●‬ ‭Debug Log‬
‭○‬ ‭A debug log has the following sections:‬
‭■‬ ‭The header‬
‭●‬ ‭Contains the version of the API used during the transaction‬
‭●‬ ‭The log category‬

‭11‬
 ‭●‬ ‭Level used to generate the log‬

‭■‬ ‭An execution unit‬

‭●‬ ‭Equivalent to a transaction‬
‭●‬ ‭It contains everything that occurred within the transaction‬
‭●‬ ‭EXECUTION_STARTED and EXECUTION_FINISHED delimit an‬
‭execution unit‬
‭■‬ ‭A code unit‬
‭●‬ ‭is a discrete unit of work within the transaction‬
‭■‬ ‭Log lines‬
‭●‬ ‭are included inside units of code and indicate which code or‬
‭rules are being executed.‬
‭●‬ ‭Debug Log Details‬
‭○‬ ‭The execution unit begins with EXECUGION_STARTED, ends with‬
‭EXECUTION_FINISHED, and contains everything that occurred within the‬
‭transaction, including the CODE UNIT.‬

‭●‬ ‭Set Up Debug Logging‬

‭○‬ ‭A debug level is a set of log levels (NONE, ERROR, WARN, FINE, etc.) that is‬
‭defined for each of the log categories (Database, Workflow, Validation, etc.)‬
‭○‬ ‭Therefore, it determines the type and amount of information that is logged in‬
‭a debug log.‬

‭○‬ ‭Log Levels:‬

‭■‬ ‭Log levels available in Apex are (Listed from Lowest to highest)‬

‭12‬
 ‭●‬ ‭None‬

‭○‬ ‭NONE prevents the category from logging‬

‭●‬ ‭Error‬

‭○‬ ‭ERROR is for logging errors‬

‭●‬ ‭Warn‬

‭●‬ ‭Info‬

‭●‬ ‭Debug‬

‭○‬ ‭DEBUG is for logging user-supplied values‬

‭●‬ ‭Fine‬

‭●‬ ‭Finer‬

‭●‬ ‭Finest‬

‭○‬ ‭The LIMIT_USAGE_FOR_NS debug event includes SOQL‬

‭queries and their limit usage and is under Apex Profiling‬
‭debug category. The recommended debug level on the‬
‭trace flag is FINEST to access this event.‬
‭○‬ ‭A trace flag is used to specify the user or entity type for which the‬
‭information is captured in a debug log.‬
‭○‬ ‭Available Trace Entity Types‬
‭■‬ ‭Specific users,‬
‭■‬ ‭Apex classes,‬
‭■‬ ‭Apex triggers‬
‭■‬ ‭Automated Process‬
‭■‬ ‭Platform Integration‬

‭13‬
 ‭■‬
‭○‬ ‭Debug logs are automatically deleted after a certain period depending on‬
‭their type.‬
‭○‬ ‭The ‘View All Data’ permission is what is required in order to access debug‬
‭logs.‬
‭●‬ ‭Managing Perspectives in the Log Inspector‬
‭○‬ ‭Developers may create a custom perspective or modify an existing‬
‭perspective. In the Developer Console > Log Inspector > Debug > View Log‬
‭Panels > Select the panels you want to include in the perspective. If you‬
‭modify a perspective, an * is appended to the perspective name until it is‬
‭saved. And, to change the default perspective, Perspective name > Set‬
‭Default.‬
‭●‬ ‭Checkpoint Inspector‬
‭○‬ ‭The Checkpoint Inspector has 2 tabs‬

‭■‬ ‭Heap‬
‭●‬ ‭Types‬
‭○‬ ‭It shows the objects that were instantiated and the‬
‭memory consumed in bytes.‬
‭●‬ ‭Instance‬
‭○‬ ‭It shows the instances of a particular object type‬
‭●‬ ‭State‬
‭○‬ ‭It shows the object’s fields and values at a particular‬
‭checkpoint‬

‭14‬
 ‭■‬ ‭Symbols‬
‭●‬ ‭Displays all symbols in memory at a checkpoint using a tree‬
‭view.‬

‭Given a scenario, know how and when to use the Salesforce Developer‬
‭tools such as Salesforce DX, Salesforce CLI, and Developer Console.‬

‭●‬ ‭Scratch Orgs‬

‭○‬ ‭For the purpose of development and testing. It is possible to create a‬
‭dedicated, configurable, and short-term development environment called a‬
‭‘scratch org’.‬
‭○‬ ‭A scratch org can be created using a Developer Hub org (also called Dev‬
‭Hub), the Salesforce CLI, and a scratch org definition file.‬
‭○‬ ‭A Developer Hub is the main org that is used to create and manage scratch‬
‭orgs via Salesforce CLI commands.‬
‭■‬ ‭For example, the ‘sfdx force:org:create’ command allows creating a‬
‭new scratch org.‬
‭○‬ ‭Scratch orgs are configurable Salesforce environments that have limited‬
‭space and lifespan, and can be used as dedicated development‬
‭environments for developers working on specific packages, fixes, or updates.‬
‭○‬ ‭A scratch org can also be used in automated testing where a continuous‬
‭integration platform such as Jenkins can automatically push code to it and‬
‭execute unit tests when changes are detected in a code repository.‬
‭○‬ ‭A scratch org is NOT designed for sharing between multiple developers.‬
‭■‬ ‭It can be replicated though by generating another scratch org using its‬
‭configuration file or from a snapshot of the scratch org.‬
‭○‬ ‭Scratch orgs serve a different purpose than sandboxes and are not meant to‬
‭replace them.‬
‭○‬ ‭In Salesforce DX, source development use cases are aligned to scratch orgs,‬
‭whereas release and deployment testing are aligned with sandbox orgs.‬

‭15‬
 ‭●‬ ‭Anonymous Blocks‬
‭○‬ ‭Like in a regular transaction, data changes made in an anonymous block will‬
‭be committed to the database.‬
‭○‬ ‭Anonymous blocks always run as the current user.‬
‭○‬ ‭Anonymous blocks can be compiled and executed using the Developer‬
‭Console, Visual Studio Code, Code Builder, or via a SOAP API call.‬
‭○‬ ‭The Tooling API can also be used to execute anonymous block via REST calls.‬
‭●‬ ‭How Salesforce Developer Experience (DX) Tooling Changes the Way You‬
‭Work‬
‭○‬ ‭Salesforce DX involves the use of‬‭Salesforce CLI‬‭to‬‭migrate code and‬
‭metadata between orgs, and generate scratch orgs, which serve as personal‬
‭development environments for developers and packages or updates‬
‭○‬ ‭A‬‭version control system‬‭is used to manage and track‬‭changes‬
‭■‬ ‭With code and metadata hosted in a code repository, Salesforce CLI‬
‭can effectively be used to implement continuous integration and‬
‭continuous deployments.‬
‭○‬ ‭By using the‬‭Salesfroce Extensions Pack‬‭for Visual‬‭Studio Code, a developer‬
‭can easily set up a Salesfroce DX project, perform Salesforce CLI commands‬
‭among several other integrated features, and build Lightning Components,‬
‭Apex, and Visualforce in the editor. Code Builder, which is a web-based‬
‭integrated development environment, possesses the capabilities to Visual‬
‭Studio Code, Salesforce extensions, and Salesforce CLI and can also be used‬
‭in developing Salesforce applications using Salesforce DX.‬

‭16‬
 ‭○‬
‭○‬ ‭The Developer Console, a web-based IDE that is connected to only one org‬
‭would not be ideally involved in the development process of a Salesforce DX‬
‭project. Since Salesforce CLI is already used to migrate metadata between‬
‭orgs, using change set is not considered part of the application lifecycle in‬
‭Salesforce DX.‬
‭●‬ ‭Checkpoints Tab‬
‭○‬ ‭The Checkpoints tab in the Developer Console provides the following‬
‭information:‬
‭■‬ ‭Namespace, Class, Line, and Time(DateTime).‬

‭○‬

‭17‬
‭Describe the environments, requirements, and process for deploying‬
‭code and associated configurations‬

‭●‬ ‭project delete source‬

‭○‬ ‭Salesforce CLI, which also uses metadata API under the hood, is a command‬
‭line tool that can be used to create, retrieve, deploy, as well as delete‬
‭metadata from any connected org.‬
‭○‬ ‭Salesforce CLI commands, which start with “sf” ( or “sfdx” for older API‬
‭versions), can be used to delete metadata from an org.‬
‭○‬ ‭To delete specific metadata, the “sf project delete source -metadata”‬
‭command is used.‬
‭●‬ ‭Deploy Using Change Sets‬
‭○‬ ‭Change sets are not available in Developer Edition orgs.‬
‭○‬ ‭Change sets are available in some editions including Enterprise and‬
‭Unlimited.‬
‭○‬ ‭The orgs need to be related in order to use change sets for migrating‬
‭metadata.‬
‭●‬ ‭Unsupported Metadata Types‬
‭○‬ ‭Certain components cannot be retrieved or deployed with Metadata API, and‬
‭changes to them must be made manually in the Salesforce org.‬
‭○‬ ‭These include components such as‬
‭■‬ ‭Account Teams‬
‭■‬ ‭Case Team Roles‬
‭■‬ ‭Currency Exchange Rate‬
‭■‬ ‭Calendars‬
‭■‬ ‭Etc.‬
‭●‬ ‭Sandbox Types and Templates‬
‭○‬ ‭Full Sandbox‬

‭■‬ ‭Only full sandboxes support performance testing, load testing, and‬
‭staging‬

‭18‬
 ‭■‬ ‭A full sandbox is a replica of the production org, including all data,‬
‭such as object records and attachments, and metadata.‬

‭■‬ ‭The length of the refresh interval makes it difficult to use Full‬
‭sandboxes for development.‬

‭○‬ ‭Partial Copy sandbox‬

‭■‬ ‭Used for quality assurance tasks, such as user acceptance testing,‬
‭integration testing, and training.‬

‭○‬ ‭Developer and Developer Pro sandboxes‬

‭■‬ ‭Intended for development and testing in an isolated environment.‬

‭■‬ ‭However, Developer Pro sandboxes can also be used for QA tasks.‬

‭○‬ ‭NOTE:‬

‭■‬ ‭Developer Pro and Partial Copy sandbox orgs cannot be used to‬
‭publish apps in AppExchange.‬

‭●‬ ‭Developer Edition or Sandbox Environment?‬

‭○‬ ‭An Enterprise Developer Edition or Scratch Pro org does not exist.‬

‭○‬ ‭A‬‭Partner Developer Edition‬‭is a licensed version‬‭of the free Developer‬

‭Edition org and comes with more data storage, licenses, as well as users.‬

‭○‬ ‭A‬‭Trial Production org‬‭is a trial version of the production‬‭org and comes‬
‭with sample data and features based on the org edition to allow customers‬
‭to try out and evaluate the platform before subscribing.‬

‭○‬ ‭A‬‭Scratch org‬‭is a source-driven short-lived org that‬‭is used in development‬

‭and automation.‬

‭○‬ ‭Production org‬‭- the production instance or live environment‬‭that contains‬

‭real data and users of the organization,‬

‭19‬
 ‭○‬ ‭Sandbox org‬‭- a nearly identical copy of the production org‬

‭○‬ ‭Developer org‬‭- a Developer Edition org which is a‬‭copy of the Enterprise‬
‭Edition org but with limited storage and users.‬

‭○‬

‭20‬