There are two development models you can follow with Salesforce DX.
First is the package model where you develop against a scratch org and prepare all the components that are needed to deploy, similar to change sets but smarter as it handles the dependencies for you. We will talk about this more in the future.
The other method is what you would be most familiar with if you have been developing with Salesforce for sometime now(Force.com IDE/Mavensmate/IntelliJ), you develop changes against a sandbox and move the metadata to deploy to the target org till you deploy to production.
With Salesforce DX you can still continue to develop against a sandbox. You do not need to enable Dev Hub for developing against a sandbox or DE org.
Requirements ofcourse if you should have VSCode installed, the VSCode Salesfor ce Extension Pack and the Salesforce CLI.
Boot up VSCode and Open the Command Prompt and type SFDX : Create Project with Manifest
The scaffolding created will contain a manifest folder with a package.xml
The default package.xml adds the base ApexClass, ApexComponent, ApexPage, ApexTestSuite, ApexTrigger,AuraDefinitionBundle and StaticResource.
Next is to Authorise the Sandbox you want to work on, Go to the command pallete. SFDX: Authorize and Org.
Next right click on the package.xml and choose Retrieve Source in Manifest in Org.
Time flies when you are having fun. 2019 was indeed full of fun and I felt like I was leaving the dream. To add to that some of the goals I aimed to do I was able to accomplish and picked up some more goals along the way.
Some personal highlights in family, wellness, and finances,
returning from a remarkable California trip in January. I never thought I could bring my family to the US but eventually did it.
still trying to be a better version of myself by investing in health. Did my first Spartan race and enrolled in Calisthenics class to further improve my skills
I’m starting a new habit of posting regularly on my blog every week. I’ll be kicking it off with tips for creating a generic class or a mocking factory for mocking calls to an external third-party service.
Why do we need to do a mock?
When running unit tests the platform does not allow to do a callout to external dependencies. To test our code base we would need to mock the response as if calling the third party dependency.
By mocking we focus on the code being tested, isolating it from the state and behavior of the external system. The dependencies are simulated and the output state can be controlled.
To start we create a class that implements the HttpCalloutMock. This class enables sending a fake response when doing HTTP callouts. When our code makes a callout, the response will come from our HttpCalloutMock class.
When creating the class we define the constructor and parameters. We can make it generic and serve as a mock factory. Instead of writing several mock classes for every type of response, we only write it once which promotes code reusability best practices. And during unit testing, we define the mock response on the fly.
Here is our sample class which implements the HttpCalloutMock.
And if we have a class that does an HTTP Callout and we want to write a unit test for it. This is how it going to look like.
This is how we would create a unit test.
Use named credentials when possible when doing HTTP Callouts. Will talk about this more in the future.
When writing the unit test, the key is to call Test.setMock() which makes sure any callout from your code will return the Mock object.
Define the mock response on the fly to test different response.
Hope you find this useful. Stay tuned for more coding content and tips. If interested in the source code it is available in GitHub.
My first post of the year and what better way to kick off but by having a fresh new theme layout. I have lots of stuffs plan for the my blog this year so stay tune.
Anyway my 2018 was probably the busiest I have been as I reached new goals in terms of career and knowledge. I managed to knocked down Salesforce and integration certification one after another like dominoes. I’m now eligible to take the Salesforce Certified Technical Architect exam board.
These are the certifications I achieved for 2018.
Salesforce Certified Sharing and Visibility Designer
Salesforce Certified Application Architect
Salesforce Certified Data Architecture & Management Designer
Salesforce Certified Identity and Access Management Designer
Salesforce Certified System Architect
Salesforce Certified Development Lifecycle & Deployment Designer
Salesforce Certified Field Service Lightning Consultant
Certified Mule 4 Developer
Certified Boomi Developer
But there is one hurdle, my weakness, my kryptonite.. my presentation skills lacks evoking confidence. (feedback from one of the senior manager). I need to up my game on my communication skills and be more engaged.
For 2019 I’m approaching stuffs a little differently. First off I need to fix my damn finances as I really let go on 2018. I barely invested, didn’t build assets and got myself into some debt( not huge) but I do not normally get into debts.
My mentality and approach this year is to build assets as well as upping my communication skills.
I’ll be starting a free series of Youtube tutorials for Salesforce Architecture, Mulesoft and web development – this should increase my subscribers and get me back on the Youtube Partner Program
I’ll start a paid course in Salesforce and Mulesoft
Not too serious approach on my merch that I sell in Amazon
Scratch my itch and build some mobile app
Build a Saas – brain dump my knowledge on CICD, etc.
Colloborate more and try to get Salesforce MVP status (how this is an asset I don’t know yet)
So basically anything that I do should lead to building an asset. It could be passive income projects, part time work to buy assets like real estate, stocks and crypto.