How to PASS Salesforce Certified Platform Developer I Exam (Part 2 of 2)

In the first part of the 2-part blog series, we covered Logic and Process Automation. Let's cover the remaining sections of the Certification to get you ready for the exam.

Testing

Describe the testing framework and requirements for deployment.

Unit test methods take no arguments, commit no data to the database, send no emails, and are flagged with the testMethod keyword or the @isTest annotation in the method definition. Also, test methods must be defined in test classes that are annotated with @isTest. Classes and methods defined as @isTest can be either private or public . Use the @TestVisible annotation to allow test methods to access private or protected members of another class outside the test class. At least 75% of your Apex code must be covered by unit tests, and all of those tests must complete successfully, before you can deploy code to a production org. Lastly, every trigger must have some test coverage.

Are there any limits around this feature?

Whenever possible, you should create test data for each test. You can disable this restriction by annotating your test class or test method with the @IsTest(SeeAllData=true) annotation.

Describe how to write unit tests for triggers, controllers, and classes.

The best practices for writing test cases are:

• Single action - test the code for a single action or record
• Bulk actions - test code for bulk actions or records
• Positive behavior
• Negative behavior
• Restricted user (use runAs() method) - Your code in the production org will be run under the context of different users. Therefore, the test must handle gracefully all possible Users that will potentially interact with the code.

Describe when and how to use various sources of test data.

There are several ways of providing test data to test methods.

• You can use Test.loadData() method to load test data without having to create it programmatically. Create a csv file with the test data and add it as a Static Resource.
• You can also create utility test classes to create test data programmatically.
• Use test setup methods (methods that are annotated with @testSetup) to create test records once and then access them in every test method in the test class. If a test method changes those records, such as record field updates or record deletions, those changes are rolled back after each test method finishes execution. The next executing test method gets access to the original unmodified state of those records.

Note that you cannot use @testSetup in combination with @isTest(SeeAllData=true) as test data cannot be isolated from real data during test execution.

Describe how to execute one or multiple test classes.

You can use a variety of tools to run one or multiple unit tests:

• Salesforce User Interface
• Force.com IDE
• Developer Console
• Soap and REST API
• Third-party IDEs

A few additional notes (gathered from the Apex Developer Guide):

• Apex tests that are started from the Salesforce user interface (including the Developer Console) run asynchronously and in parallel.
• Apex tests that run as part of a deployment always run synchronously and serially. You can use the runTests() call from the SOAP API to run tests synchronously.
• You can also run tests using the Tooling REST API. Use the /runTestsAsynchronous/ and /runTestsSynchronous/ endpoints to run tests asynchronously or synchronously.
• You can also run tests asynchronously using ApexTestQueueItem and ApexTestResult. This process enables you to not only start tests asynchronously but also schedule your tests to execute at specific times by using the Apex scheduler.
• Using the runAs() method you can run tests in the context of another user (that can be created duirng in @testSetup) to enforce record sharing. runAs() method does not enforce any permissions.
• The startTest() method marks the point in your test code when your test actually begins. Each test method is allowed to call this method only once. All of the code before this method should be used to initialize variables, populate data structures, and so on, allowing you to set up everything you need to run your test. Any code that executes after the call to startTest() and before stopTest() is assigned a new set of governor limits.
• The stopTest() method marks the point in your test code when your test ends. Use this method in conjunction with the startTest() method. Each test method is allowed to call this method only once. Any code that executes after the stopTest() method is assigned the original limits that were in effect before startTest was called. All asynchronous calls made after the startTest method are collected by the system. When stopTest() is executed, all asynchronous processes are run synchronously.
• Use Test.setFixedSearchResults to define the set of records that should be returned when testing SOSL queries.

Describe the differences between invoking Apex in execute anonymous vs. unit tests.

Unit tests are executed in system mode and any changes made to records are not visible outside of their test execution context. Whereas with anonymous block, any changes performed to data are visible after its execution is successful. Code written in anonymous block is not stored as metadata in salesforce org and user permissions are enforced during execution.

Data Modeling and Management

Given a set of requirements, determine the appropriate data model.

Following are the different relationships available in Salesforce (again pulled directly from Salesforce documentation):

• Lookup - Lookup relationships can be one-to-one or one-to-many. Typically, you use lookup relationships when objects are only related in some cases. Sometimes a contact is associated with a specific account, but sometimes it's just a contact. Objects in lookup relationships usually work as stand-alone objects and have their own tabs in the user interface.
• External lookup - An external lookup relationship links a child standard, custom, or external object to a parent external object. When you create an external lookup relationship field, the standard External ID field on the parent external object is matched against the values of the child's external lookup relationship field. External object field values come from an external data source.
• Indirect lookup - An indirect lookup relationship links a child external object to a parent standard or custom object. When you create an indirect lookup relationship field on an external object, you specify the parent object field and the child object field to match and associate records in the relationship. Specifically, you select a custom unique, external ID field on the parent object to match against the child's indirect lookup relationship field, whose values come from an external data source.
• Master-Detail - In a master-detail relationship, the detail object doesn't work as a stand-alone. It's highly dependent on the master. In fact, if a record on the master object is deleted, all its related detail records are deleted as well. When you're creating master-detail relationships, you always create the relationship field on the detail object. The Owner field on the detail and subdetail records is not available and is automatically set to the owner of the master record. Custom objects on the "detail" side of a master-detail relationship can't have sharing rules, manual sharing, or queues, as these require the Owner field. Detail and subdetail records inherit security settings and permissions from the master record. You can't set permissions on the detail record independently.
• Hierarchical - Finally, you could run into a third relationship type called a hierarchical relationship. Hierarchical relationships are a special type of lookup relationship. The main difference between the two is that hierarchical relationships are only available on the User object. You can use them for things like creating management chains between users.

Describe the capabilities of the various relationship types and the implications of each on record access, user interface (UI), and object-oriented programming.

Most of this got covered already in the previous topic.

Describe the impact of schema design and modifications on Apex Development.

Fields referenced in code can't change their data type, API name, or be deleted. In order to make changes to fields, you would need to first comment out or otherwise replace all references to the field in your code, make the changes to the field, and then uncomment or update the code afterwards. This means that if you're deploying from one org to another, you might need two deployments, depening on the type of change. You will also probably want to back up the data before you start, and possibly restore the data when you're done.

Describe how to visualize and create entity relationships.

Salesforce provides a tool to visualize your schema. You can search for it in the Setup by typing Schema Builder. It will be a good idea to generate a diagram of your org and look at the different options available to show/hide various aspects of the Schema.

Describe the options for and considerations when importing and exporting data into development environments.

Here are the considerations for the various data import/export tools available:

• Use the Data Import Wizard When:
  • You need to load less than 50,000 records.
  • The objects you need to import are supported by the wizard.
  • You don't need the import process to be automated.
• Use Data Loader When:
  • You need to load 50,000 to five million records.
  • You need to load into an object that is not supported by the Data Import Wizard.
  • You want to schedule regular data loads, such as nightly imports.
• Salesforce offers two main methods for exporting data.
  • Data Export Wizard: This is an in-browser wizard, accessible through the Setup menu. It allows you to export data manually once every six days (for weekly export) or 28 days (for monthly export). You can also export data automatically, at weekly or monthly intervals.
  • Data Loader

User Interface

Describe how to display Salesforce data using a Visualforce page.

You can use a variety of techniques and OOTB visualforce tags to display data from the org. Some examples are:

• {!Account.Name}
• <a href="https://developer.salesforce.com/docs/atlas.en-us.pages.meta/pages/pages_compref_detail.htm" target="_blank" rel="noreferrer noopener"><code></code></a>
• <a href="https://developer.salesforce.com/docs/atlas.en-us.pages.meta/pages/pages_compref_relatedList.htm" target="_blank" rel="noreferrer noopener"><code></code></a>
• <a href="https://developer.salesforce.com/docs/atlas.en-us.pages.meta/pages/pages_compref_outputField.htm" target="_blank" rel="noreferrer noopener"><code></code></a>
• <a href="https://developer.salesforce.com/docs/atlas.en-us.pages.meta/pages/pages_compref_pageBlockTable.htm" target="_blank" rel="noreferrer noopener"><code></code></a>

Describe the types of web content that can be incorporated into Visualforce pages

Apart from plain-old HTML, you can also display:

• Maps
• Charts
• Flows
• PDF and custom content type. Use to specify custom content type.

Describe how to incorporate Visualforce pages into Force.com applications.

You can either create a new visualforce page by just typing the name of the page in the URL and Salesforce would create an empty page, it no renderer exists for that URI; OR you can replace an existing OOTB page with your own. Here are quick guides for each:

• Creating Your First Page
• Overriding an Existing Page with a Visualforce Page

Describe the benefits of the Lightning Component framework.

At a high level, Lightning offers the following benefits (over Visualforce):

• Out-of-the-Box Component Set - Salesforce provides a number of components to bootstrap your app development.
• Performance - The component framework leverages a stateful client (using JavaScript) and a stateless server (using Apex). This structure allows the client to call the server only when absolutely necessary. With fewer calls to the server, your apps are more responsive and efficient.
• Event-Driven Architecture - Events are key to the Lightning component framework. Components listen to application and component events and respond accordingly. Rapid Development - The simple markup and pre-made components mean that you can get applications out the door faster than ever. Particularly if you're comfortable with Visualforce markup, learning component markup is a breeze.
• Device-Aware and Cross-Browser Compatibility - A huge advantage of Lightning components is that you don't have to worry about compatibility across devices and browsers. The component framework handles this work for you.

Describe the resources that can be contained in a Lightning Component.

The following link provides a great outline of the types of resources that can be contained in a Lightning Component Bundle.

Debug and Deployment Tools

Describe how to monitor and access various types of debug logs.

The simplest way of accessing debug logs is to open up the Salesforce Developer Console before running the action or transaction for which you'd like to see the logs of. Additional information, including how to read debug logs, can be found at Working with Logs in the Developer Console

Describe the capabilities and security implications of the Developer Console, Workbench, and Force.com IDE.

The Force.com IDE can be used to:

• Test and debug Apex classes and triggers using the Apex Test Results view.
• Run anonymous blocks of Apex on the server in the Execute Anonymous view.
• Browse schema objects and fields or assemble and execute SOQL queries in the Schema Explorer.
• Synchronize project contents with changes on the server using Save to Server, Refresh from Server, and Synchronize with Server commands.
• Utilize the Compare Editor to merge changes when conflicts are detected.
• Deploy metadata components from one Salesforce organization to another, or validate a planned deployment without saving changes, using the Deploy to Server wizard.

Developer Console can be used to:

• View Logs
• Run tests
• View Checkpoints
• Run SOQL and SOSL queries
• View "View State"
• View Deployment Progress
• Compilation Errors
• View Code Coverage by class
• Rerun Failed Tests
• Enable/Disable "Always Run Asynchronously"

Describe the different processes for deploying metadata and business data.

I would highly recommend reviewing the Change Management best practices outlined in this Trailhead.

Are there any limits around this feature?

Yesss! Although Salesforce is constantly expanding upon the Metadata API, you will likely encounter metadata that is not (yet) supported by the Metadata API. In other words, changes to such metadata has to be tracked so it can be deployed manually. The Unsupported Metadata Types lists metadata types that are not supported by the API

Describe how the different environments are used in the development and deployment process.

Broadly speaking, there are three types of environments:

• Production Environments - Salesforce.com environments that have active paying users accessing business critical data
• Development Environments - Salesforce.com environments where you can extend, integrate and develop on Force.com without affecting your production environments
• Test Environments - These can be Production or Development Environments specifically used for testing application functionality before deploying to production or releasing to customers

Are there any limits around this feature?

Only Developer Edition or Partner Developer Edition environments can create managed packages.

Salesforce fundamentals

Describe the considerations when developing in a multi-tenant environment.

The biggest impact to developing in a multi-tenant environment like Salesforce, is that you are working with shared and limited resources. Therefore the platform limits your code in several ways to make sure your code does not consume resources in a way where it could negatively impact other clients. The Governors in Apex Code page does a great job of expanding upon this topic.

Describe how the Salesforce platform features map to the MVC pattern.

A picture is worth a thousand words. The following images (pulled from Visualforce Developer Guide) illustrate how Salesforce adopts the MVC paradigm. It is slightly different for Lightning, but the concepts remain the same.

Describe the capabilities of the core CRM objects in the Salesforce schema.

The following trailheads provide a great way of getting to know these basics:

• Accounts & Contacts
• Leads & Opportunities

Identify the common scenarios for extending an application's capabilities using the AppExchange.

Just like in traditional Software Development, it is preferred to not re-create the wheel. Similarly, in the Salesforce world, if you encounter scenarios that feel like someone might have already solved that problem, then it would be a good idea to search for it on the AppExchange. You can find packages that are as small as a data table component to as large as an entire ERP system. The Creating an AppExchange Strategy provides some insight on determining your organization's AppExchange Strategy.

Given a scenario, identify common use cases for declarative customization.

Some common use cases are:

• Creating a new Object
• Modifiying fields of an existing object
• Record Types
• Validation Rules
• Processes

That wraps up the entire Study Guide. Hope you are feeling more confident in taking the exam now. Don't forget to take the sample tests. Best of Luck!