Trilha de estudo
Trilha Desenvolvedor Salesforce (Apex & LWC): tudo o que estudar, tópico por tópico
Avaliação de nível certificação para desenvolvedores Salesforce: fundamentos de Apex, gestão de dados e transações (governor limits, bulkification, Apex assíncrono), triggers e lógica de automação, Lightning Web Components (LWC), integração e APIs (callouts, platform events) e testes, segurança e deployment (Apex tests, CRUD/FLS, SFDX, packaging) — alinhada às certificações Salesforce Platform Developer I e II.
Resposta curta
Para aprender Desenvolvedor Salesforce (Apex & LWC), percorra 6 módulos e 45 tópicos na ordem em que um apoia o próximo. Comece por Fundamentos da Linguagem Apex e siga para Gestão de Dados e Transações e Triggers e Lógica de Automação. Use o mapa como checklist, ou meça seu nível e estude só o que falta.
O que você vai estudar
Os tópicos estão agrupados por módulo. Abra um para ver os objetivos e os conceitos-chave.
1 · Fundamentos da Linguagem Apex8 tópicos
Apex Syntax & Primitive Data Types
Core Apex language constructs: primitive types (String, Integer, Long, Decimal, Boolean, Date, DateTime, Id), type casting, null handling, and Apex vs Java differences developers must know for the Platform Developer I exam.
Objetivos
- Identify and correctly use Apex primitive types and the Id type
- Handle null values safely to avoid NullPointerException at runtime
- Explain key syntactic differences between Apex and Java
Conceitos-chave
- Apex primitive types
- Id data type
- null handling in Apex
- type casting
- Apex vs Java differences
- String methods
Collections: List, Set & Map
Apex collection types — List (ordered, allows duplicates), Set (unordered, unique), and Map (key-value) — their iteration patterns, common methods, and usage in bulk-safe governor-limit–aware code.
Objetivos
- Choose the correct collection type for a given data-management scenario
- Iterate over collections safely in bulk Apex contexts
- Use Map<Id, SObject> patterns to avoid repeated SOQL inside loops
Conceitos-chave
- List<T>
- Set<T>
- Map<K,V>
- iteration with for loop
- collection methods (add/remove/contains/keySet)
- nested collections
SOQL & SOSL in Apex
Embedding SOQL and SOSL queries inline in Apex: SELECT syntax, WHERE/ORDER BY/LIMIT, relationship queries, dynamic SOQL via Database.query(), SOSL multi-object search, and query governor limits.
Objetivos
- Write correct inline SOQL with relationship traversal in both directions
- Use dynamic SOQL safely, avoiding SOQL injection via bind variables
- Distinguish when to use SOSL over SOQL for cross-object text search
Conceitos-chave
- inline SOQL
- WHERE / ORDER BY / LIMIT clauses
- parent and child relationship queries
- dynamic SOQL (Database.query)
- SOSL FIND syntax
- query governor limit (100 queries / 50,000 rows)
DML Statements & Database Methods
DML operations (insert/update/upsert/delete/undelete/merge) as statements and via Database class methods; partial-success AllOrNothing flag; DmlException handling; and record-level SaveResult/UpsertResult inspection.
Objetivos
- Perform DML using both statements and Database methods, choosing the right approach
- Inspect SaveResult arrays to identify and report partial failures
- Use upsert with External ID fields for idempotent data loads
Conceitos-chave
- insert / update / upsert / delete
- Database.insert(records, allOrNone)
- SaveResult and UpsertResult
- DmlException
- External ID upsert
- merge statement
Control Flow & Exception Handling
Apex control flow constructs: if/else, for/while/do-while loops, break/continue; custom and system exceptions; try/catch/finally; exception properties and best practices for rollback-safe error handling.
Objetivos
- Implement loop patterns that remain governor-limit–safe across large data sets
- Create and throw custom exceptions with meaningful messages for LWC error handling
- Structure try/catch/finally blocks to preserve transaction integrity
Conceitos-chave
- if / else if / else
- for loop variants (traditional, list, SOQL cursor)
- try / catch / finally
- custom exception classes
- Exception.getMessage / getStackTraceString
- System.AuraHandledException
sObjects & Schema Introspection
sObject types, generic vs specific sObject, runtime Schema.describeSObjectResult, Schema.DescribeFieldResult, field tokens, and dynamic field access via SObject.get()/put() for flexible, metadata-driven Apex.
Objetivos
- Use Schema Describe calls to build metadata-driven Apex logic
- Access and mutate sObject fields dynamically using string-based field names
- Retrieve Record Type info at runtime without hardcoding Record Type IDs
Conceitos-chave
- sObject type hierarchy
- Schema.describeSObjectResult
- Schema.DescribeFieldResult
- SObjectField token
- SObject.get(fieldName) / SObject.put(fieldName, value)
- getRecordTypeInfosByDeveloperName
Apex Classes & Interfaces
Class anatomy in Apex: constructors, static vs instance context, inner classes, virtual/abstract/interface contracts, and common design interfaces such as Comparable, Schedulable, Database.Batchable, and Queueable.
Objetivos
- Design Apex class hierarchies using inheritance and interface contracts
- Explain when to use abstract vs interface and how they affect testing
- Implement inner classes as lightweight data-transfer objects
Conceitos-chave
- static vs instance members
- virtual and abstract classes
- interface keyword
- inner classes
- Comparable interface
- class instantiation patterns
Apex Properties & Access Modifiers
Apex access modifiers (private/protected/public/global), property syntax with custom get/set accessors, the with sharing / without sharing / inherited sharing keywords, and the @AuraEnabled annotation for LWC exposure.
Objetivos
- Apply the correct access modifier for encapsulation and namespace safety
- Configure with sharing classes to enforce record-level security
- Annotate Apex methods with @AuraEnabled correctly for LWC consumption
Conceitos-chave
- private / protected / public / global
- property get / set accessors
- with sharing / without sharing
- inherited sharing
- @AuraEnabled annotation
- @AuraEnabled(cacheable=true)
2 · Gestão de Dados e Transações8 tópicos
Governor Limits
Salesforce multi-tenant governor limits enforced per transaction: SOQL query count, DML row and statement counts, heap size, CPU time, callout limits, and how to monitor them with Limits class methods.
Objetivos
- List the most critical governor limits and their default thresholds
- Use Limits class methods to proactively check remaining capacity at runtime
- Identify code patterns that will breach governor limits under bulk loads
Conceitos-chave
- 100 SOQL queries per transaction
- 150 DML statements per transaction
- 10,000 DML rows per transaction
- Limits.getQueries() / Limits.getLimitQueries()
- heap size limit
- CPU time limit (10,000 ms sync)
Bulkification Patterns
Design patterns for governor-limit–safe Apex: collecting IDs before SOQL, building Map<Id, SObject> result maps, performing single DML on collections, avoiding SOQL/DML inside loops, and the 200-record trigger batch contract.
Objetivos
- Refactor SOQL-inside-loop code to a single bulk query pattern
- Apply Map<Id, SObject> to correlate records without repeated queries
- Design trigger handlers that correctly support 200+ record batches
Conceitos-chave
- SOQL inside loop anti-pattern
- Map<Id, SObject> lookup pattern
- collecting records before DML
- 200-record trigger batch
- Selector layer pattern
- Unit of Work pattern
SOQL Relationship Queries & Aggregates
Parent-to-child (subquery) and child-to-parent (dot notation) relationship queries, aggregate functions (COUNT/SUM/AVG/MIN/MAX/GROUP BY), HAVING clause, and SOQL for loops as a cursor for large result sets.
Objetivos
- Write parent-to-child subqueries and traverse results in Apex
- Use aggregate SOQL with GROUP BY to compute summary metrics
- Apply SOQL for loops to process millions of records without heap overflow
Conceitos-chave
- parent-to-child subquery
- child-to-parent dot notation
- aggregate functions (COUNT/SUM/AVG)
- GROUP BY and HAVING
- AggregateResult type
- SOQL for loop (cursor)
Bulk DML Operations & Partial Success
Database.insert/update/upsert with allOrNone=false, iterating SaveResult arrays, error collection and surface strategies, Database.UpsertResult for external-key operations, and the Apex transaction rollback boundary.
Objetivos
- Use Database methods with partial-success mode and surface per-record errors
- Design error-reporting patterns that surface failures back to callers
- Explain how partial success interacts with the transaction rollback boundary
Conceitos-chave
- Database.insert(records, false)
- SaveResult.isSuccess() / getErrors()
- Database.UpsertResult
- allOrNone=true vs false
- partial success error collection
- transaction rollback boundary
Transaction Control & Savepoints
Database.setSavepoint() and Database.rollback() for partial transaction reversal, rollback semantics (DML only, not governor limit counts), and patterns for compensating transactions in multi-step workflows.
Objetivos
- Implement savepoint-rollback patterns for conditional multi-step DML
- Explain what a rollback does and does not reset within a transaction
- Identify scenarios where savepoints improve data integrity
Conceitos-chave
- Database.setSavepoint()
- Database.rollback(sp)
- Savepoint type
- rollback does not reset limit counters
- compensating transaction pattern
- nested savepoint limitations
Order of Execution
The Salesforce record-save order of execution: system validations, before triggers, duplicate rules, after triggers, assignment rules, workflow rules, processes, flows, escalation rules, and the implications for Apex developers.
Objetivos
- Describe the full Salesforce record-save order of execution step by step
- Explain why workflow field updates can re-trigger Apex triggers
- Anticipate interaction effects between triggers, flows, and validation rules
Conceitos-chave
- system validation (required fields, data type)
- before triggers
- after triggers
- workflow field updates re-firing triggers
- process builder and flow in execution order
- duplicate management rules
Asynchronous Apex: Future & Queueable
@future methods for deferred callouts and mixed DML, Queueable interface for chaining and monitoring, System.enqueueJob(), AsyncApexJob tracking, and governor limit changes in async context.
Objetivos
- Implement @future methods to perform callouts from trigger context
- Use Queueable to chain asynchronous steps and monitor job status
- Compare @future, Queueable, Batch, and Scheduled Apex use cases
Conceitos-chave
- @future(callout=true)
- Queueable interface
- System.enqueueJob()
- AsyncApexJob object
- chaining Queueable jobs
- higher heap/CPU limits in async
Batch Apex & Scheduled Apex
Database.Batchable interface (start/execute/finish), Database.executeBatch() scope parameter, stateful Batch Apex, Schedulable interface and CRON expressions, and designing Batch jobs that are bulkification-safe and testable.
Objetivos
- Implement a Batch Apex job with start/execute/finish for large data processing
- Use Database.Stateful to accumulate state across execute batches
- Schedule Batch Apex via Schedulable and CRON expressions
Conceitos-chave
- Database.Batchable<SObject>
- start / execute / finish methods
- Database.executeBatch(job, scope)
- Database.Stateful interface
- Schedulable interface
- System.schedule() with CRON
3 · Triggers e Lógica de Automação7 tópicos
Trigger Context Variables
Apex trigger context variables: Trigger.new, Trigger.old, Trigger.newMap, Trigger.oldMap, Trigger.isInsert/isUpdate/isDelete/isUndelete, Trigger.isBefore/isAfter, Trigger.size, and Trigger.operationType.
Objetivos
- Access and navigate trigger context variables for all DML operation types
- Compare field values between Trigger.new and Trigger.old to detect changes
- Use Trigger.newMap for efficient ID-based record lookups within a trigger
Conceitos-chave
- Trigger.new / Trigger.old
- Trigger.newMap / Trigger.oldMap
- Trigger.isInsert / isUpdate / isDelete
- Trigger.isBefore / isAfter
- Trigger.operationType
- Trigger.size
Trigger Design Patterns (Handler Framework)
One trigger per object pattern, trigger handler class separation of concerns, domain-driven dispatch (fflib/Apex Enterprise Patterns), and the TriggerHandler base class pattern for routing context to typed methods.
Objetivos
- Implement the one-trigger-per-object pattern with a handler class
- Design a TriggerHandler base class that dispatches to typed context methods
- Explain the maintainability benefits of the handler framework over inline logic
Conceitos-chave
- one trigger per object rule
- TriggerHandler base class
- handler dispatch by context
- fflib ApexTriggerHandler
- separation of trigger routing from business logic
- trigger handler unit testing
Before vs After Triggers
Semantic differences between before and after triggers: when Trigger.new is mutable, when record IDs are available, field updates in before context, and the correct context for querying related records.
Objetivos
- Determine whether to use before or after trigger context for a given use case
- Modify record fields in before trigger without an extra DML statement
- Query related records safely in after trigger when IDs are available
Conceitos-chave
- before trigger — record not yet saved
- after trigger — record has ID and is in database
- modifying Trigger.new in before context
- querying inserted record in after context
- before insert / before update / before delete
- after insert / after update / after undelete
Recursion Control
Preventing infinite trigger loops with static Boolean flags, Set<Id>-based deduplication, and context-aware recursion guards; understanding how workflow field updates and process builders can re-invoke triggers.
Objetivos
- Implement a static Boolean flag to prevent trigger recursion
- Use a Set<Id> guard for more granular recursion deduplication
- Trace the execution path that causes recursion via workflow field updates
Conceitos-chave
- static Boolean flag pattern
- Set<Id> processed IDs guard
- trigger recursion via workflow field update
- recursion depth limit (16 levels)
- before-update triggered by after-update DML
- context-aware guard reset
Trigger vs Flow Decision Framework
Decision criteria for choosing Apex triggers over record-triggered flows and vice versa: complexity, governor limit implications, testability, maintainability by admins, and Salesforce's 'automate first' guidance aligned with PDI/PDII exam scenarios.
Objetivos
- Apply the Salesforce automation decision framework to select the right tool
- Identify cases where Apex triggers are unavoidable over declarative flows
- Explain governor limit considerations that differ between triggers and flows
Conceitos-chave
- record-triggered flow
- Apex trigger complexity threshold
- admin maintainability vs developer flexibility
- governor limits in flows
- Salesforce Well-Architected guidance
- combining flows and triggers
Platform Events in Apex
Publishing and subscribing to Platform Events from Apex: EventBus.publish(), trigger on platform event object, event bus delivery guarantee, ResumeCheckpoint for after-errors-only resume, and decoupled async patterns.
Objetivos
- Publish Platform Events from Apex triggers and handlers
- Consume Platform Events in an Apex trigger with ReplayId management
- Explain at-least-once delivery and idempotency requirements for subscribers
Conceitos-chave
- Platform Event definition (API name __e)
- EventBus.publish()
- trigger on MyEvent__e
- ReplayId
- at-least-once delivery
- EventBus.getOperationId()
Apex-Invoked Flows & Flow-Invoked Apex
Calling flows from Apex via Flow.Interview, passing input variables; invoking Apex from flows using @InvocableMethod; InvocableVariable types; bulkification contract for invocable methods and error surface patterns.
Objetivos
- Annotate an Apex method with @InvocableMethod for consumption by flows
- Design InvocableVariable inner classes with correct bulk List<> signatures
- Invoke a named flow from Apex using Flow.Interview and inspect outputs
Conceitos-chave
- Flow.Interview.createInterview()
- @InvocableMethod annotation
- @InvocableVariable annotation
- List<Request> / List<Result> pattern
- bulkification in invocable methods
- flow fault path vs exception propagation
4 · Lightning Web Components (LWC)8 tópicos
LWC Component Structure (HTML/JS/Meta)
Anatomy of a Lightning Web Component: the HTML template file, the JavaScript controller class, the XML metadata configuration, CSS scoping, and the component bundle directory convention.
Objetivos
- Create a valid LWC bundle with correct naming conventions and file structure
- Configure the meta.xml file to expose a component on App/Record/Home pages
- Explain how shadow DOM scoping affects CSS in LWC vs Aura components
Conceitos-chave
- component bundle (HTML + JS + CSS + meta.xml)
- template tag and data binding
- JavaScript class extending LightningElement
- meta.xml targets and API version
- shadow DOM and CSS scoping
- SLDS (Salesforce Lightning Design System) classes
Reactive Properties: @track, @api & @wire
LWC reactivity model: @api for parent-exposed public properties, @track for deep object/array reactivity, the default shallow reactivity of class fields, and @wire as a decorator for data binding to wire adapters.
Objetivos
- Distinguish @api, @track, and undecorated reactive property behavior
- Expose a public property with @api and validate it in connectedCallback
- Explain when @track is still necessary vs relying on default reactivity
Conceitos-chave
- @api public property
- @track deep reactivity
- default shallow reactivity (LWC Spring 20+)
- @wire decorator
- property vs function wire target
- reactive setter pattern
Wire Service & Apex Methods
Wiring Apex methods and Salesforce wire adapters (getRecord, getPicklistValues, getRelatedListRecords) to LWC components; wire function target for reactive parameter passing; error and data destructuring patterns.
Objetivos
- Wire a cacheable Apex method to a component with a reactive parameter
- Handle wire data and error states in the component template
- Use standard Salesforce wire adapters to load record data declaratively
Conceitos-chave
- @wire(apexMethodName, param: $reactiveValue)
- wire result { data, error } destructuring
- getRecord wire adapter
- getPicklistValues wire adapter
- reactive wire parameter with $ prefix
- cacheable=true requirement for wire
Lightning Data Service & Base Components
LightningRecordViewForm, LightningRecordEditForm, LightningInputField, LightningOutputField, and the LDS cache for automatic record operations; lightning-button, lightning-card, lightning-datatable, and other base components.
Objetivos
- Build record create/edit/view forms using LDS base components without custom Apex
- Configure lightning-datatable with typed columns and row actions
- Explain how the LDS cache updates propagate across components on the same page
Conceitos-chave
- lightning-record-view-form / lightning-record-edit-form
- lightning-input-field / lightning-output-field
- LDS record cache
- lightning-datatable columns definition
- lightning-card / lightning-button
- SLDS utility classes
Event Handling: Custom Events & Pub/Sub
LWC event model: firing custom events with new CustomEvent(), handling events in parent with template listeners, event bubbling and composed flag, and pub/sub (LMS — Lightning Message Service) for cross-tree communication.
Objetivos
- Fire and handle custom events between child and parent LWC components
- Control event propagation using bubbles and composed attributes
- Implement cross-component communication using Lightning Message Service
Conceitos-chave
- new CustomEvent('name', { detail })
- this.dispatchEvent(event)
- on<eventname> handler in parent template
- bubbles and composed flags
- Lightning Message Service (LMS)
- MessageChannel publication and subscription
Navigation & NavigationMixin
Programmatic navigation in LWC using NavigationMixin.Navigate() and NavigationMixin.GenerateUrl(); page reference types (standard__recordPage, standard__namedPage, standard__objectPage, comm__namedPage); and navigation in Experience Cloud contexts.
Objetivos
- Navigate to a record, object list, and named page using NavigationMixin
- Generate a URL for a page reference and render it as an anchor link
- Adjust navigation page references for Experience Cloud contexts
Conceitos-chave
- NavigationMixin import
- NavigationMixin.Navigate(pageRef)
- standard__recordPage pageReference
- standard__namedPage (Home, Chatter, etc.)
- standard__objectPage
- Experience Cloud comm__namedPage
Imperative Apex Calls
Calling Apex methods imperatively from LWC JavaScript: promise-based invocation, async/await pattern, error handling with try/catch, and when to prefer imperative calls over @wire (user-initiated actions, non-cacheable mutations).
Objetivos
- Call a non-cacheable Apex method imperatively from a button click handler
- Use async/await with try/catch to handle Apex errors in LWC
- Refresh a wired property using refreshApex after an imperative DML call
Conceitos-chave
- import apexMethod from salesforce/apex/ClassName.methodName
- apexMethod({ param }).then().catch()
- async / await with try / catch
- non-cacheable Apex for DML
- refreshApex after mutation
- AuraHandledException message surface
LWC Lifecycle Hooks
LWC component lifecycle: constructor, connectedCallback, renderedCallback, disconnectedCallback, errorCallback; rendering lifecycle guarantees; and best practices for initialization, DOM access, and cleanup.
Objetivos
- Explain when each lifecycle hook is called during component mount and unmount
- Access DOM elements safely in renderedCallback with a first-render guard
- Implement errorCallback to catch and surface child component errors
Conceitos-chave
- constructor()
- connectedCallback()
- renderedCallback()
- disconnectedCallback()
- errorCallback(error, stack)
- this.template.querySelector in renderedCallback
5 · Integração e APIs7 tópicos
REST & SOAP Callouts (HttpRequest/HttpResponse)
Making outbound callouts from Apex: HttpRequest configuration (endpoint, method, headers, body, timeout), HttpResponse status code and body parsing, XML/JSON deserialization, and callout governor limits.
Objetivos
- Construct and send an HTTP REST callout with correct headers and body
- Parse a JSON response into an Apex inner class using JSON.deserialize()
- Explain why callouts cannot be made from synchronous trigger context
Conceitos-chave
- HttpRequest / Http / HttpResponse classes
- setEndpoint / setMethod / setHeader / setBody
- JSON.deserialize() / JSON.serialize()
- 10-second callout timeout (default)
- callout from @future or Queueable
- 10 callouts per transaction limit
Named Credentials & Authentication
Named credentials as endpoint + auth containers, Legacy vs Per-User named credentials, credential types (Password, OAuth, AWS Signature), external credential principals, and eliminating hardcoded endpoint URLs from Apex code.
Objetivos
- Configure a Named Credential to handle OAuth 2.0 authentication for callouts
- Reference a Named Credential in an HttpRequest endpoint
- Explain the difference between Legacy Named Credentials and External Credentials
Conceitos-chave
- Named Credential (endpoint + auth)
- callout:NamedCredentialName URL prefix
- Legacy vs External Credential
- OAuth 2.0 flow in named credentials
- per-user credential principal
- eliminating hardcoded URLs
Apex REST & Custom Web Services
@RestResource and @HttpGet/@HttpPost/@HttpPut/@HttpPatch/@HttpDelete annotations, RestRequest and RestResponse context objects, URL path parameter binding, and SOAP web services via the webservice keyword.
Objetivos
- Implement a custom Apex REST endpoint with URL mapping and HTTP method annotations
- Read request body and URL parameters from RestContext.request
- Return structured JSON responses via RestContext.response
Conceitos-chave
- @RestResource(urlMapping='/api/v1/*')
- @HttpGet / @HttpPost / @HttpPut
- RestContext.request / RestContext.response
- URL parameter binding from urlMapping
- webservice keyword for SOAP
- global class requirement
Platform Events & Change Data Capture
Platform Events for event-driven integration: publishing via Apex and flows, subscribing via CometD and Apex triggers; Change Data Capture (CDC) event objects, ChangeEventHeader fields, and CDC use cases for external system synchronization.
Objetivos
- Design an event-driven integration pattern using Platform Events
- Subscribe to Change Data Capture events to sync Salesforce changes externally
- Compare Platform Events and CDC for integration architecture decisions
Conceitos-chave
- Platform Event API name (__e suffix)
- EventBus.publish() from Apex and flows
- CometD long-polling subscription
- Change Data Capture (CDC)
- ChangeEventHeader (changeType, changedFields)
- CDC entity channel subscription
External Services & OpenAPI Import
Registering External Services from an OpenAPI 2.0/3.0 spec, auto-generated invocable actions for flows, named credential binding, schema evolution considerations, and when External Services is preferred over hand-coded callouts.
Objetivos
- Register an External Service from an OpenAPI spec in Setup
- Use an auto-generated External Service action in a record-triggered flow
- Explain schema evolution considerations when updating an External Service
Conceitos-chave
- External Services registration from OpenAPI spec
- auto-generated flow invocable actions
- Named Credential binding to External Service
- schema versioning impact
- External Services vs custom Apex callout
- Flow-driven API invocation
Bulk API & Streaming API Overview
Bulk API 2.0 for large-scale data loads/extracts, job lifecycle (upload/close/abort), CSV batch format; Streaming API (PushTopic and Generic Streaming) for real-time notifications; developer awareness for PDII integration scenarios.
Objetivos
- Describe the Bulk API 2.0 job lifecycle for large-volume data operations
- Explain when to choose Bulk API over REST API for data integration
- Compare PushTopic Streaming, Platform Events, and CDC for real-time use cases
Conceitos-chave
- Bulk API 2.0 job types (ingest / query)
- job states (Open/UploadComplete/InProgress/JobComplete/Failed)
- PushTopic for Streaming API
- CometD client for Streaming
- Generic Streaming API
- Bulk API vs REST API throughput trade-offs
Integration Security & Remote Site Settings
Remote Site Settings for whitelisting callout endpoints, CSP Trusted Sites for LWC/Aura, OAuth 2.0 flows for inbound Salesforce APIs (Web Server, Username-Password, JWT Bearer), connected apps, and API security best practices.
Objetivos
- Configure Remote Site Settings to allow outbound callouts to an endpoint
- Select the correct OAuth 2.0 flow for a server-to-server integration scenario
- Set up a Connected App for external system access with appropriate scopes
Conceitos-chave
- Remote Site Settings (whitelist callout endpoint)
- CSP Trusted Sites for LWC
- OAuth 2.0 Web Server flow
- OAuth 2.0 JWT Bearer flow
- Connected App configuration
- API rate limits and throttling
6 · Testes, Segurança e Deployment7 tópicos
Apex Unit Tests & Test Data (@TestSetup)
@isTest class structure, @TestSetup shared data factory, Test.startTest()/stopTest() for governor limit resetting, System.assertEquals/assertNotEquals/assert, and seeAllData=false discipline for test isolation.
Objetivos
- Structure an Apex test class with @TestSetup and multiple @isTest methods
- Use Test.startTest() and Test.stopTest() to reset governor limits and flush async
- Enforce test isolation with seeAllData=false and self-contained test data
Conceitos-chave
- @isTest class annotation
- @TestSetup method
- Test.startTest() / Test.stopTest()
- System.assertEquals(expected, actual)
- @isTest(seeAllData=false)
- test data isolation
Code Coverage & Assertions
Salesforce 75% org-wide code coverage requirement for production deployments, 75% per-class trigger coverage, meaningful assertions vs coverage-only tests, and best practices for assertion completeness aligned with PDII exam expectations.
Objetivos
- Explain the 75% code coverage requirement and how it is measured
- Write assertions that validate business logic, not just inflate coverage
- Ensure trigger tests cover bulk scenarios with at least 200 records
Conceitos-chave
- 75% org-wide code coverage threshold
- 75% per-trigger coverage
- System.assert / assertEquals / assertNotEquals
- coverage vs meaningful assertions
- covering bulk paths (200 records)
- running tests in developer console vs deploy
Mocking: StubProvider & HttpCalloutMock
HttpCalloutMock interface for testing callouts, Test.setMock() registration, StaticResourceCalloutMock for complex responses; StubProvider interface for dynamic dependency mocking in unit tests without real DML or callouts.
Objetivos
- Implement HttpCalloutMock to simulate REST API responses in Apex tests
- Use StubProvider to mock service-layer dependencies without hitting the database
- Register mocks with Test.setMock() and Test.createStub() correctly
Conceitos-chave
- HttpCalloutMock interface
- Test.setMock(HttpCalloutMock.class, mock)
- StaticResourceCalloutMock
- StubProvider interface
- Test.createStub()
- dependency injection in testable Apex
Apex Security: CRUD/FLS, Sharing & Security_ENFORCED
Enforcing record-level sharing with with sharing keyword, checking CRUD and FLS with Schema.describeSObjectResult/DescribeFieldResult, the WITH SECURITY_ENFORCED SOQL clause, and stripInaccessible() for field-level filtering.
Objetivos
- Enforce object and field CRUD/FLS checks before DML and SOQL operations
- Apply WITH SECURITY_ENFORCED to SOQL queries as an alternative to manual checks
- Use Security.stripInaccessible() to filter inaccessible fields from query results
Conceitos-chave
- with sharing / without sharing / inherited sharing
- isCreateable() / isUpdateable() / isDeletable()
- isAccessible() for field-level security
- WITH SECURITY_ENFORCED SOQL clause
- Security.stripInaccessible()
- SObjectAccessDecision
SFDX & Source-Driven Development
Salesforce DX (SFDX) CLI: project structure (sfdx-project.json), scratch org creation and features, source push/pull, org shape, and the shift from change-set to source-driven development workflows.
Objetivos
- Create a scratch org from a feature definition file using SFDX CLI
- Push and pull source between a scratch org and the project repository
- Explain the advantages of source-driven development over change-set deployment
Conceitos-chave
- sfdx-project.json
- scratch org
- sf org create scratch / sf project deploy start
- source format vs metadata format
- org shape feature definition
- dev hub and scratch org limits
Unlocked Packages & 2GP Managed Packages
Unlocked packages for modular org development: package creation, versioning, install/upgrade; Second-Generation Managed Packages (2GP) for ISVs: namespace, subscriber protections, deprecation, and package dependency management.
Objetivos
- Create, version, and install an unlocked package using SFDX CLI
- Explain the subscriber protection model for 2GP managed packages
- Manage package dependencies and version promotion for production release
Conceitos-chave
- sf package create / package version create
- unlocked package install
- package dependency tree
- 2GP namespace locking
- subscriber-protected metadata
- package version promotion
CI/CD & Deployment (Metadata API, Scratch Orgs)
CI/CD pipeline design for Salesforce: SFDX CLI in CI (GitHub Actions / GitLab CI), sf project deploy start with --test-level RunLocalTests, deployment validation (check-only), metadata API retrieve/deploy, and the full path from scratch org to production sandbox to production.
Objetivos
- Design a CI/CD pipeline that runs tests and validates before deploying to production
- Use check-only deployment and quick deploy to minimise production downtime
- Explain the differences between MDAPI format and source format deployments
Conceitos-chave
- sf project deploy start --check-only
- --test-level RunLocalTests / RunAllTestsInOrg
- metadata API (MDAPI) retrieve and deploy
- GitHub Actions SFDX pipeline
- sandbox refresh strategy
- deployment validation and quick deploy
Níveis: Júnior, Pleno, Sênior e Especialista
Explique com suas palavras
Corrigido por IA · sem cadastro · 1 perguntaSem alternativas para chutar: você escreve, a IA corrige com a rubrica do tópico e diz em que nível sua resposta está.
Já estuda Desenvolvedor Salesforce (Apex & LWC)?
A avaliação mede tópico por tópico, e o plano pula o que você já sabe.
Aberto para ler. A conta só é necessária para ser medido.
Perguntas frequentes
Por onde começar a estudar Desenvolvedor Salesforce (Apex & LWC)?
Comece por Fundamentos da Linguagem Apex: Apex Syntax & Primitive Data Types, Collections: List, Set & Map e SOQL & SOSL in Apex. O mapa ordena os tópicos pelo que depende de quê, então cada um prepara o seguinte.
Quanto tempo leva uma avaliação completa de Desenvolvedor Salesforce (Apex & LWC)?
Uma avaliação completa desta trilha leva cerca de 45 minutos. O tempo de estudo depende de onde você começa; o diagnóstico mostra quais tópicos você pode pular.
Preciso de conta para usar esta página?
Não. O mapa, os objetivos e os conceitos-chave são abertos. A conta só é necessária para ser medido, ver seu gap por tópico e receber um plano.