DEV Community: Matheus Goncalves

How to mock formulas and read-only fields in Apex tests?

Matheus Goncalves — Fri, 25 Mar 2022 22:07:46 +0000

Learn how to use dependency injection to mock read-only fields, such as formula fields and child relationships in your tests.

A while ago we explored the Mock Data Layer Pattern, which allows us to mock virtually any relationships between records within your tests. This is especially handy when trying to improve the performance of these tests - more details here.

Now, how can we mock formula fields and read-only child relationships if they are, well, read-only fields? 🤔

Mocking values in read-only fields

For this exploratory project, we will use a not-so-realistic scenario with parent and child accounts, but the intent is to create a test for the Account Trigger Handler that will use a Mock Field Reader and a Mock Data Layer.

The Mock Field Reader will be used so we can mock two read-only fields on the Account object.

Child_Accounts__r, a read-only child relationship on the parent record
External_URL__c, a formula field on the child record

The trigger handler logic will update the following field:

Parent.Latest_Child_URL__c

Based on the following formula field:

Child.External_URL__c

⚙️ Files used in this project

force-app
    main
        default
            classes
                ◦ AccountTriggerHandler
                ◦ AccountTriggerHandlerTest
                ◦ FieldReader
                ◦ IFieldReader
                ◦ MockFieldReader
                ◦ TestUtils
            triggers
                ◦ AccountTrigger

⚡️ Show me the code!

Getters

To respect the injected dependency, these methods must be present on both the real instance of the field reader ( FieldReader ) and the mock instance of the field reader ( MockFieldReader ).

Object getFieldValue(SObject record, String fieldName)

This method is used to retrieve the mock values of formula fields. It returns an Object that can later be casted as different types, such as String, Number, Id, etc.

SObject getFieldRecord(SObject record, String fieldName)

This method is used to retrieve the mock values that represent a single record. It returns an SObject.

List<SObject> getFieldRecords(SObject record, String fieldName)

This method is used to retrieve the mock values that represent a list of records, such as a child relationship. It returns a list of SObjects.

Setter

There's only one method used to set the values, and it's only present on the mock instance of the field reader ( MockFieldReader ).

addValueToField(SObject record, String field, Object value)

This method adds the field/value pair to a map of mocked values, indexed by the record Id.

Examples

In the repository on Github you will find a trigger handler class and its respective test class with the usage of this Mock Field Reader.

Snippet from the AccountTriggerHandler: pay attention to how the following methods are being used:

fieldReader.getFieldRecords(parentAndChildAccount, 'Child_Accounts__r');

fieldReader.getFieldValue(latestChild, 'External_URL__c');

And in the AccountTriggerHandlerTest you can see how these read-only fields can be mocked, using the method addValueToField:

With this code and the Mock Field Reader, it becomes easy to mock read-only fields used in the tests.

I hope that helps!

Originally published on matheus.dev

The growth stages of a programmer

Matheus Goncalves — Thu, 15 Aug 2019 21:22:04 +0000

▫️ I don't know what I'm doing...
▫️ Let me copy this code block from the Internet
▫️ Hey, if it works, it works!
▫️ It's working, but it needs to follow the best practices and design patterns.
▫️ Let's refactor it!
▫️ I don't know what I'm doing...
▫️ Aha!

How to select the Salesforce release for a Scratch Org

Matheus Goncalves — Mon, 29 Jul 2019 19:52:14 +0000

Did you know you can specify the release (preview or previous) when creating a scratch org?

That is especially helpful when testing your code against future features in Preview orgs, but it’s even more than that:

During every major Salesforce release, you have the opportunity to get early access to the release in your scratch orgs and sandboxes to test new customizations and features before your production org is upgraded. This is called the Salesforce Preview, and scratch orgs created on the upcoming release are called preview scratch orgs.

This way you not only can try out new features in an upcoming release, to check if they will fit your needs but also by running your applications in preview orgs, you can proactively check if your code is in good shape or if there will be a breaking change.

Then you can add any future bug to your backlog and plan your work accordingly, with fewer surprises.

Normally, you create scratch orgs that are the same version as the Dev Hub. However, during the major Salesforce release transition that happens three times a year, you can select the Salesforce release version, Preview or Previous, based on the version of your Dev Hub.

Before this change, you would have to create a trial Dev Hub on the upcoming version to create preview scratch orgs. Now you can use your existing Dev Hub that includes your existing scratch org active and daily limits.

Because previous and preview are all relative terms, your Dev Hub org version during the release transition determines their relative significance. Here’s what happens when you try to create a scratch org with one of the release values.

Dev Hub Version	Preview	Previous
Dev Hub has upgraded to the latest version	Error (Dev Hub is already on the latest version)	Prior Dev Hub version
Dev Hub is still on the GA version	Version following the Dev Hub version (newly released Salesforce version)	Error (Dev Hub is on the GA version; previous version unavailable)

Important note: If you don’t specify a release value, the scratch org version is the same as the Dev Hub org.

Create a Scratch Org for a Specific Release

You can specify the release version in the scratch org definition file or directly on the command line. Any option you issue on the command line overrides what you have defined in your scratch definition file.

Find out which instance your Dev Hub org is on: status.salesforce.com.
Add the release option to your scratch org definition file:

If you’re planning on using some sort of script to spin up a new scratch org, or you just prefer using the command line, you can specify the release value directly on the CLI!

Please note the use of the release keyword: release=Preview

If you’re creating a previous scratch org and you have upgraded the CLI to the pre-release version, be sure to set the apiVersion to match the scratch org version.

To set it globally for all DX projects:

To set it on the command line:

What If I Want to Create a Pre-Release Scratch Org?

Pre-release is a very early build of the latest version of Salesforce that’s available before Salesforce Preview. It’s not built to handle scale and doesn’t come with any Salesforce Support service-level agreements (SLAs).

For this reason, the only way to create a pre-release scratch org is to sign up for a pre-release trial Dev Hub org (subject to availability).

This article was originally published in matheus.dev.

How to Query Salesforce Code Coverage

Matheus Goncalves — Tue, 18 Sep 2018 02:13:32 +0000

In Salesforce Orgs, code coverage percentage is a calculation of the number of covered lines divided by the sum of the number of covered lines and uncovered lines.

In addition to ensuring the quality of your code, unit tests enable you to meet the code coverage requirements for deploying or packaging Apex. To deploy Apex or package it for the Salesforce AppExchange, unit tests must cover at least 75% of your Apex code, and those tests must pass.

After running tests, you can view code coverage information in the Tests tab of the Developer Console. The code coverage pane includes coverage information for each Apex class and the overall coverage for all Apex code in your organization.

However, you can also use SOQL queries with Tooling API as an alternative way of checking code coverage and a quick way to get more details. Let's see how it works:

Inspecting Code Coverage

Step 1 - Get your org's base URL:

If you know what's your Org's base URL (you can get it from your browser as well), please jump to step 2.

From Developer Console, open the Debug menu, then select the option "Open Execute Anonymous Window (CTRL+E)
Enter the following Apex Code:


    String baseURL =  'https://' + System.URL.getSalesforceBaseUrl().getHost();
    System.debug(baseURL);

Click the button [Execute]
Go to your Logs tab on the bottom of the page
Copy the full Base URL, including https://

Step 2 - Now you know your base URL, create a Remote Site Setting

From Setup, enter Remote Site Settings in the Quick Find box, then select Remote Site Settings.
Click New Remote Site.
Enter a descriptive term for the Remote Site Name.
Enter the URL for the remote site.
Optionally, enter a description of the site.

Click Save.
Just in case, create a second Remote Site Settings for the URL in the "Visual.force.com" format:
- https://c.xx99.visual.force.com - where xx99 is the code of your org's instance.

Step 3 - Get the JSON file for the Code Coverage Wrapper

Go back to the Developer Console, open the Debug menu, then select the option "Open Execute Anonymous Window (CTRL+E)
Enter the following Apex Code:

Click the button [Execute]
Go to your Logs tab on the bottom of the page
Copy the full JSON result

Please note you will need to remove any text before the first "{" bracket.
Eg.: "hh:mm:ss:999 USER_DEBUG [99]|DEBUG|"

Go to the website JSON2Apex: https://json2apex.herokuapp.com/
Paste your JSON file
Enter the name for the generated class (here, we will use CodeCoverageWrapper)
Click the button [Create Apex]

Download the generated zip file that contains the Wrapper class plus the Test class.
Extract the files
Open the files with your prefered text editor
Check if everything looks good, and add these classes to your Salesforce org as new classes.

This is how it looks like:

Step 4 - Create a Helper Class

Create the following class, that contains a method that will query and return information about the Code Coverage

Don't forget to write the test class for it.

Step 5 - Create a Controller and a Page to display the Code Coverage

Create the following class, that contains the logic for the page

Create the following page, using the controller we just created.

Please note we're leveraging Salesforce Lightning Design System;

The page has two buttons. One to sort the results by Class / Trigger name, and another button to sort the results by Code Coverage.

This is how it looks like:

Final Considerations

You can follow the same logic to use the Tooling API whenever you need to query exposed metadata used in developer tooling that you can access through REST or SOAP.

Also, the method sortCodeCoverageMapByCoverage from CodeCoverageHelper is quite handy and can be used as an example for situations when you need to sort Maps by its values. In this case, sort the Code Coverage percentage value.

Just don't forget to adapt the Wrapper and the Comparable.

You can find all code used for this project in my GitHub account, at github.com/gitmatheus/QueryCodeCoverage

gitmatheus / QueryCodeCoverage

How to Query Code Coverage - After running tests, you can view code coverage information in the Tests tab of the Developer Console. The code coverage pane includes coverage information for each Apex class and the overall coverage for all Apex code in your organization. However, you can also use SOQL queries with Tooling API as an alternative way of checking code coverage and a quick way to get more details.

How to Query Code Coverage

In Salesforce Orgs, code coverage percentage is a calculation of the number of covered lines divided by the sum of the number of covered lines and uncovered lines. In addition to ensuring the quality of your code, unit tests enable you to meet the code coverage requirements for deploying or packaging Apex.

To deploy Apex or package it for the Salesforce AppExchange, unit tests must cover at least 75% of your Apex code, and those tests must pass. After running tests, you can view code coverage information in the Tests tab of the Developer Console. The code coverage pane includes coverage information for each Apex class and the overall coverage for all Apex code in your organization. However, you can also use SOQL queries with Tooling API as an alternative way of checking code coverage and a quick way to get more details.

The code…

View on GitHub

I hope you enjoyed the ride and learned something new today.

See you next time.

This article was originally posted at matheus.dev

Time traveling, dreams and gratitude

Matheus Goncalves — Thu, 31 May 2018 06:07:59 +0000

I just found a picture of my house in mid-2001. Look at this mess!

A back house, suburbs of São Paulo, Brazil. One bedroom, a kitchen and an outdoor bathroom.

That was... it.

And I was making money with tech support, fixing computers and programming video rental systems in Clipper. Something like this:

It was a lot of fun. Seriously. But I could never imagine that in 2018 I would be working with Salesforce for one of the best technology companies in the world, and living in Seattle. Not in my best dreams.

All I knew at that time was that I was living by myself, trying really hard to make a living.

I was 19 years old, and I needed to continue studying and working, learning, and trying to be a better person and professional every day. That was my plan.

I think it's important to look back and see where I came from, and remember everything I went through, to give even more value to what I have today, to have gratitude for all this and for everyone who helped me. ❤️

So: If you think your dream is an unreachable thing, impossible, maybe you're already living part of it and you don't even know it.

Keep Fighting! 🤜🤛

Unit Test: Can we mock relationships in Salesforce Apex?

Matheus Goncalves — Tue, 24 Apr 2018 04:38:12 +0000

I've been trying to use some of my spare time to help my fellow Salesforce Developers in our community. And one of the best places to do so, is Salesforce Stack Exchange.

And a few days ago someone posted the following question:

How can I write a test method without actually doing the query (to speed up test run times)? As far as I know, the only way to return relationships more than one level deep is to query for them. I know ApexMock has IDGenerator but cannot see how I can use it for this use case?

Well, can we mock relationships in Apex to improve a test's performance?

And the answer is yes, it's possible. I'm going to explain how to achieve that in incremental steps, to try to simplify the concept.

You can mock virtually any relationship if you use a Mock Data Layer Pattern.

Imagining the scenario presented by the developer in that question, you could add an Interface to your main class. Let's call it IDataLayer. Add this new interface to the main class (here, called DataLayerHandler.cls)

Now, in the same class, let's create an inner class for this data layer, implementing the Interface you just created:

Ok, now how to access it? We need to create an instance of this DataLayer, and we will use the DataLayerHandler Class constructor for that. This is really important, I'll explain it below:

But why to do all of that?! And this is the magic: because now you can pass a MOCK version of the data layer to you class to use!! Given this handler class, let's create a test class and a mock class, implementing the same interface:

With the mock version of the data layer, you can start creating your mock records. Use the method getFakeId(Schema.SObjectType type) to create Ids to your mock records:

There you go. This way you can mock several different types of relationships.

This is an extremely useful pattern and allow you to test your logic in different scenarios without running queries, without hitting the database. It's a good way to improve your tests performance.

Just don't forget to create some bulkified tests as well.

I hope that helps!

Salesforce DX: Useful CLI Commands

Matheus Goncalves — Tue, 03 Oct 2017 13:13:21 +0000

Salesforce DX is finally available and it is amazing! Now professional developers can build collaboratively with continuous delivery using Salesforce DX, the open and integrated experience that makes development on the Salesforce Platform easy.

I strongly recommend you to watch this presentation, made by Wade Wegner, with an introduction to Salesforce DX, talking about principles of Modern Software Delivery, how DX will improve the Developer Experience, some patterns and anti-patterns and how to adopt Salesforce DX:

Well, once you decide to switch, you'll notice that you can use the Salesforce command-line interface (CLI) for most Salesforce DX tasks. These tasks include authorizing a Dev Hub org, creating a scratch org, synchronizing source code between your scratch orgs and VCS, and running tests.
You can start using the CLI right after you install it.

The CLI commands are grouped into top-level topics. For example, the force top-level topic is divided into topics that group commands by functionality, such as the force:org commands to manage your orgs.

Run ---help at each level to get more information.

sfdx --help // lists all top-level topics
sfdx force --help // lists all the topics under force
sfdx force:org --help // lists all the commands in the topic force:org
sfdx force:org:open --help // detailed info about the force:org:open command

Imagine you want to login to your Hub Org:

sfdx force:auth:web:login --setalias my-hub-org --instanceurl https://login.salesforce.com

Imagine now that you want to login to your sandbox:

sfdx force:auth:web:login --setalias my-sandbox --instanceurl https://test.salesforce.com

Maybe you want to get a list to all orgs you're connected to:

sfdx force:org:list

To open one of these orgs:

sfdx force:org:open -u my-sandbox

To mark a scratch org for deletion:

sfdx force:org:delete -u my-sandbox

To remove an old hub org, or non-scratch org from Salesforce DX org list, you need to manually cleanup the DX configs in the local installation. It would be nice for this to be something in the actual CLI commands: the ability to clean up old orgs that are no longer needed. For the time being, use the following steps:

On Mac OS and Linux, you can find your DX config folder, called .sfdx, in your user home directory.

cd ~/.sfdx

On Windows, you can use

%USERPROFILE%.sfdx

In that folder there are a host of .json files, named for the username of the admin user you registered for that org. In my case, in this instance it was called mgoncalves@dx.pilot, so sure enough, there it was:

mgoncalves@dx.pilot.json

Inside the file, or the hashes for current access token, refresh token, and all the other OAuth goodness that allows DX to access your org. So I simply deleted that file:

> rm mgoncalves@dx.pilot.json

That appears to have cleaned it all up.

To retrieve unpackaged Source Defined in a package.xml file (eg.: the file created by MavensMate):

sfdx force:mdapi:retrieve -r ./mdapipkg -u [your_username] -k ./package.xml

To retrieve an unmanaged package you want to convert to Salesforce DX:

sfdx force:mdapi:retrieve -s -r ./mdapipkg -u [your_username] -p

To convert the retrieved source Defined in a package.xml file: the first step is to unzip unpackaged.zip using a zip file management utility or from the command line. For example, on a Mac, double-click unpackaged.zip in Finder or type the following command on the command line:

unzip ./mdapipkg/unpackaged.zip -d ./mdapipkg/

Then convert the source code to the Salesforce DX project structure:

sfdx force:mdapi:convert -r ./mdapipkg

To create a scratch org, first create a JSON file with the or configuration. Then:

sfdx force:org:create -f project-scratch-def.json -a MyScratchOrg

To push changes, use a Force Push:

I mean, use this:

sfdx force:source:push -u MyScratchOrg

To push changes ignoring errors (with great powers, great responsibilities. Be careful):

sfdx force:source:push -u MyScratchOrg --ignorewarnings --forceoverwrite

Salesforce DX CLI is a powerful command line interface, a tool that simplifies development and build automation when working with your Salesforce org.

For even more information, run this command to view all available commands in the force topic.

sfdx force:doc:commands:list

See you next time.

This article was originally posted at matheusgoncalves.com

How I ended up becoming a Salesforce Developer

Matheus Goncalves — Mon, 02 Oct 2017 18:42:11 +0000

When I look back now, working with software development has been like a rollercoaster.

Everything started when I was only 13 years old, with a language called Clipper. Yes, I know. It's been a while. I remember when my dad was installing this old computer in our modest living room. It was love at first sight, and it was a lot of fun.

For the first time in my life the word "creativity" had an empirical meaning. I was creating things. Digital things, but still, things. Pieces of code doing exactly what I told them to do. That was fascinating.

After that I've been exploring this world a lot. Sudoku games with C++ or Visual Basic, complete systems with Oracle Forms 4, PL/SQL, SQL Server, Pascal/Delphi and, ultimately, becoming a Java and C# developer, trying as much as possible to become fluent on both languages.

We must constantly endeavor if we are to succeed, right? So I did. And, for years, that was my whole universe.

One day I had to integrate an old B2B Marketing application, built with Java (Struts 1.0) with a new platform. It was a CRM and it was on the clouds. Oh, the clouds, they're so magical, aren't they?

But this was my first contact with Salesforce Development. Let's say I remember the clouds because I had to learn how to build an airplane while flying.

After changing pretty much the whole project and adjusting the requirements, I started to learn how to develop custom interfaces, objects, records, Visualforce Components, Visualforce pages, Apex Statements, classes and everything I needed to accomplish my tasks.

In order to do so, I needed help, of course. So I started exploring the Salesforce Stack Exchange, one of the most important and helpful communities of Salesforce Developers.

There I learned about Salesforce triggers, some of the platform limitations, some basic SOQL statements (something equivalent to SQL, remember), and even ways to change the solution by changing the approach within the Salesforce possibilities.

In 2014 I attended Dreamforce in San Francisco. It's the must-attend tech conference of the year for anyone who's in the Salesforce Ecosystem. And that was a milestone for me.

Not only because of the free books I could get there (Force.com Fundamentals, Mobile SDK Developer Guide, Salesforce1 Mobile Mobile App Developer Guide and Heroku Programming), but also because I was in touch with the brightest minds and ideas of Salesforce universe and because it was the first time I heard about Trailhead.

If, for some reason, you don't know what Salesforce Trailhead is, imagine a way to learn more and more about how to solve problems, how to use the best practices, how to become a better developer, by taking challenging and fulfilling tasks that you can accomplish in your pace, that makes you satisfied and happy because you actually feel you are fully developing your abilities.

So by getting in touch with the most amazing and welcoming developers community there is, by learning how Salesforce lives the Ohana values every day and by learning more and more about the platform, I became a Salesforce Developer. And, in 2016, I got my Salesforce Platform Developer Certification.

I have a strong thirst for knowledge, therefore I'm aware there's so much more to learn, more badges the earn and more problems to solve. This is just the beginning. And you're more than welcome to join us.

Take a deeper dive into these values and don't forget to check the Salesforce Developer Career eBook. You may leave with some ideas you can take to your company, or begin to implement yourself.

Spoiler alert: walking this path may change your life ðŸ˜‰

This article was originally posted at matheusgoncalves.com