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
○ [Link]()
■ Call [Link]() 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 [Link]() and [Link]() methods can be used with the Limits
methods(Such as [Link](), [Link](). etc.) to
determine the amount of governed resources that have been consumed in a
specific block of code.
○ [Link]()
■ Marks the point in the test code when the test actually begins
○ [Link]()
■ Marks the point in the test code when the test ends.
○ Any code that executes after the call to [Link]() and before
[Link]() 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
○ ThesObject classprovides 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<[Link]>) 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 toprocessesandEscalation 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 ofSalesforce CLItomigrate code and
metadata between orgs, and generate scratch orgs, which serve as personal
development environments for developers and packages or updates
○ Aversion control systemis used to manage and trackchanges
■ With code and metadata hosted in a code repository, Salesforce CLI
can effectively be used to implement continuous integration and
continuous deployments.
○ By using theSalesfroce Extensions Packfor VisualStudio 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.
○ APartner Developer Editionis a licensed versionof the free Developer
Edition org and comes with more data storage, licenses, as well as users.
○ ATrial Production orgis a trial version of the productionorg and comes
with sample data and features based on the org edition to allow customers
to try out and evaluate the platform before subscribing.
○ AScratch orgis a source-driven short-lived org thatis used in development
and automation.
○ Production org- the production instance or live environmentthat 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 acopy of the Enterprise
Edition org but with limited storage and users.
○
20
