Category: SFDX

Spring’20 Brings Improved Code Coverage Result for Apex Test Class

 Writing test classes to cover both positive, negative, and bulkified scenarios are always the best practices that each developer should follow. While writing test classes, our approach should be to cover as much as code and all the scenarios. There is a restriction from Salesforce that if there is not enough coverage (75%) for the code, then Salesforce will not allow you to deploy your code to production.So identifying the code coverage is very important. Now there are multiple ways we can get to know the code coverage like – Setup menu, Developer Console, SOQL Query, Salesforce CLI, or Salesforce extension in Visual Studio Code. With so many options there comes the difficulties. Each option presents the code coverage in a different way and more importantly, each option calculates code coverage in a different way. This always creates confusion. For example, when a developer writes the test class and executes that from CLI, it provides the code coverage, let’s say 90%, which should be good enough to deploy the code into Production. But while deployment, the code coverage came down to 50%, and thus deployment stops. The reason for this drop in code coverage is that while deploying code coverage is calculated at the org level i.e. percentage of coverage for that class across the org.To solve this problem, Salesforce comes up with the Enhanced Code Coverage option. With...

Read More

Getting Started with Salesforce DX

What is Salesforce DX?Salesforce DX is a way to shift your development lifecycle and to manage your source of truth. But don’t consider Salesforce DX is going to do any magic, as a developer/release manager/lead you need to come up with your own strategy to manage your releases, other challenges like code conflict, urgent fix etc.Why we need Salesforce DX?I think the best way to answer this is with some real time scenarios.Recently I was working with one of my customer who was having multiple sandboxes like DEV, SIT, QAT, UAT. A typical scenario. Now every time there was any kind of production issues, development team tried to find out the root cause and also tried to find out if the issue was due to some of the recent releases. But since all sandboxes were having the same code as Production, there was no way to find out previous code base. So in this situation normally developer request for a new sandbox with production code and fix the issue. This type of development is known as “Org Based Development”.But consider if the code was present in some source control repository then developer can easily get the previous code base, compare code between recent releases (basically comparing between master and branches). But does that really solve our problem? Somehow, but not fully. So basically we need to create an org...

Read More
Loading