A blog dedicated to Salesforce Ohana

Salesforce Summer 15 New Feature || Predictable Iteration Order for Apex Unordered Collections

After Summer15 Salesforce release, the order of elements in unordered elements (Map and Set) is always the same. Previously the order was arbitrary and as a developer, you have no control on the order.

Now as you can see, with this new feature, we are trying to order the unordered elements. A little strange to me. But if you have some code snippet, where the logic depends on the ordering of the elements, then this new feature will be really helpful.

Let's consider the below code snippet -

If you run this code after Summer15, you will get the elements in the same order every time you execute.

21:01:19.145 (145215707)|USER_DEBUG|[10]|DEBUG|Index: 1 Employee: James
21:01:19.145 (145338304)|USER_DEBUG|[10]|DEBUG|Index: 2 Employee: Sudipta
21:01:19.145 (145498650)|USER_DEBUG|[10]|DEBUG|Index: 3 Employee: Christiaan
21:01:19.145 (145587990)|USER_DEBUG|[10]|DEBUG|Index: 4 Employee: Victor

So now your Unordered Collections are also predictable.
Share:

Salesforce Summer 15 New Feature || New way to calculate code coverage for multiline statements

In Summer 15 release, Salesforce changed the way to calculate code coverage for multiline statements. As a developer, you feel good in some situation and bad in some situations. In this post, I will explain both the situations.

Let me first explain the change -
If a single statement is broken into multiple lines, then each line will be considered now while calculating the code coverage. To be more precise, each line that contains an expression will be considered while calculating code coverage. Before Summer 15 release, multiline was considered as a single line.

To explain more, I will start with a simple code snippet.

Situation 1 - Happy Situation:
Consider the below code snippet.

Now say for example, you have written unit test methods for the methods calculateDistanceBetweenAB(), calculateDistanceBetweenBC(), calculateDistanceBetweenCD() and calculateDistanceBetweenDA().

You have also written test methods to cover line# 8,9 and 10. The only line which is not covered/tested is line# 11.

Now before Summer 15 release, the way in which code overage was calculated -
Total number of lines = 4 (line # 3,8,9 and 11)
Total number of lines covered = 3 (line # 3,8 and 9)
So the code coverage = 3/4 i.e. 75%

But after Summer 15 release, the way in which code overage will be calculated -
Total number of lines = 7 (line # 3,4,5,6,8,9 and 11)
Total number of lines covered = 6 (line # 3,4,5,6,8 and 9)
So the code coverage = 6/7 i.e. 85%

As you can see that the code coverage increases here. So for me, this is a happy situation. 

Situation 2 - Not So Happy Situation:
Consider the same code snippet.

Now say for example, you have written unit test methods for the methods calculateDistanceBetweenAB() only.

You have also written test methods to cover line# 8,9 and 10. 

Now before Summer 15 release, the way in which code overage was calculated -
Total number of lines = 4 (line # 3,8,9 and 11)
Total number of lines covered = 3 (line # 3,8 and 9)
So the code coverage = 3/4 i.e. 75%

But after Summer 15 release, the way in which code overage will be calculated -
Total number of lines = 7 (line # 3,4,5,6,8,9 and 11)
Total number of lines covered = 3 (line # 3,8 and 9)
So the code coverage = 3/7 i.e. 42%

So this is not so happy situation as you can see that code coverage decreases here. But there is always a way. You can write more test methods to increase the code coverage.

Please check the below details for your reference -

Share:

Feeling Awesome - A Gift from Salesforce Developer Community


Feeling awesome after receiving this gift from Salesforce Developer Community.

A special thanks to -
Paromita Banerjee, Jitendra Zaa, Chris Duarte, April Kyle Nassi

Salesforce Rocks!!!
Share:

How to write unit test classes for @future methods

In this post, I will explain how to write unit test classes to increase test coverage for @future methods. Let's start with a Use Case -
Use Case -
Let's say in my Account object, I have a checkbox named "notifyAdmin__c" and I would like to update this checkbox for list of Accounts in a future method.
Below is the Apex Class -

Now let's write the test class. Below is the test class -

Here is the explanation-
To test future methods, you need to simply make your future method call between Test.startTest() and Test.stopTest(). Test.stopTest() will make sure that @future method will have fired. So after Test.stopTest(), you can do all your assert.

I hope this quick example will help you to write unit test cases for your @future method. If you have any suggestion, please let me know. 
Share:

Salesforce Lightning Component Framework - All you need to know to get started...

Salesforce Lightning Component framework is really awesome. This is the framework which is having Apex on the server-side and JavaScript on the client-side. In this post, I will go through few objects, functions, concepts which will be used very frequently in most of the framework. So let's get started -

Controller -
Below is one controller function. It takes three parameters component, event, helper. 

Controller functions are used for client-side activities. For example - behavior on button click, form submit etc. can be defined inside a controller function. When calling this functions, as a developer, you don't need to set these parameters, the framework will populate them with the required values.

Helper Functions - 
This is the place where you will write all your codes which will be shared between components or sub components. If you have something non-trivial logic, you should move that to helper function and let your controller call the helper function. 

Below is one example where I am retrieving all cases. Now to retrieve cases, I need to write SOQL and that is something happening inside Apex controller (Server-Side). So my helper function getCases is calling the Apex controller's function and I am calling my handling function (getCases) from controller function. 

The advantage with this approach is that now I can call getCases whenever required from my controller. I don't need to repeat the same login every time.

Component - 
Lightning component is represented as component object in API. Below are few methods which you need to know -
  • get()/set() - These methods are used for getting and setting values from value provider. We have two different types of value providers -
    • "v" - This is attribute set value provider.
    • "c" - This is the controller (methods).
  • find() - Finds a component with a specified aura:id. It can find a simple HTML element also provided that element is having an aura:id.
  • getEvent() - Gets a component-level event. This is very much used when a component wants to fire an event that it has registered.
Event -
Lightning component event is represented as Event object in API. This is provided by the framework as parameters to the controller functions. Below are the important methods -
  • getParam() - This is used to get an attribute that was set on the event. 
  • fire() - This is used to fire an event.
  • setParams() - This is used to set parameters on the event.
Action Object -
This is used to communicate with server-side controllers. Below are few methods -
  • getReturnValue() - This is used to get the result of calling the action.
  • getState() - This is used to fetch the state of the action. This is very frequently used to check whether the server-side calling is successful or failure.
  • getError() - This is used to get an array of errors generated from a server-side action.
  • setParams() - This is used to set the parameters required for server-side methods.
  • setCallBack() - This is used to set the callback to be called when the action completes.
Utility Functions -
The API comes with few utility functions which we should know as they are very helpful. These functions are referred to as $A. Below are few utility functions -
  • $A.enqueueAction() - This is used to enqueue an action which will be called by the framework. In Lightning, you can't call any server-side functions directly, rather you will enqueue them and framework will execute those on your behalf.
  • $A.log() - This is used to log information to any subscribers of the leg level. You have to setup an subscriber to the level at which you are logging and have it handle it.
  • $A.newCmpAsync() - This is used to create a dynamic new component. A good example to display an error message by creating a dynamic component.
  • $A.getEvt() - This is used to fire an application-level event.
Lightning Component Documentation -
Your first point of source is the Lightning Components Developer's Guide. This is really well organized and contains lots of information. If you want to know more, you can always access the JavaScript API documentation @ http://<yourInstance>.salesforce.com/auradocs

Share:

Follow Me

Enter your email address:

Delivered by FeedBurner

Popular Posts

Labels

Salesforce (105) Apex (44) admin (27) ADM (20) visualforce (20) dev 501 (19) integration (18) learn salesforce (18) 501 (16) SOAP (13) lightning (12) tutorial (11) Certification. (9) javascript (8) Trigger (7) test class (7) unit testing (7) Sharing and Visibility (6) design pattern (6) report (6) security (6) trailhead (6) Advanced Admin (5) Certification (5) New Features (5) SOQL (5) css (5) dashboard (5) debug (5) developer (5) formula (5) mobile (5) salesforce release (5) service cloud (5) solution management (5) use case (5) JSON (4) Kitchener Developer Group (4) Lightning Experience (4) WebSphere (4) best practice (4) cast iron (4) component (4) deployment (4) github (4) html (4) polymer (4) profiles (4) responsive (4) tdd (4) ui (4) Advanced Apex (3) Architect (3) Live Chat (3) Performance (3) Products (3) Role (3) Sales Cloud (3) Salesforce DX (3) Scratch Org (3) Study Notes. (3) Summer15 (3) Tips (3) Web Technology (3) dynamic apex (3) event (3) license (3) map (3) mapbox (3) singleton (3) version controlling (3) Bulkify (2) Data Architecture and Management Certification (2) Distributed Version Controlling (2) ES6 (2) Eclipse (2) Einstein (2) Enterprise Territory Management (2) Financial Services Cloud (2) Force.com IDE (2) Governor Limit (2) Groups (2) IBM (2) Implicit Sharing (2) JourneyToCTA (2) Lightning Design System (2) Live Agent (2) Metadata (2) Online Event (2) Opportunity (2) Price Book (2) REST (2) SOSL (2) Sharing (2) Spring 15 (2) Summer17 (2) Territory (2) ant (2) automation tool (2) basic (2) chatter (2) coding (2) communication (2) console (2) controller (2) documentation (2) flow (2) git (2) jquery (2) logging (2) object (2) permission (2) process builder (2) release (2) salesforce1 (2) strategy (2) xml (2) Action Plan (1) Action Plan Template (1) Agent Productivity (1) Analytics (1) Apex Sharing (1) Arrow (1) Asynchronous callout (1) Aura Framework (1) Bots (1) Browser (1) Bulk data load (1) CTA (1) Calendar (1) Canon (1) Case Management (1) Cheat Sheet (1) Classic (1) Community (1) Constructor (1) Contact Center (1) Continuation (1) Continuous Integration (1) Convert (1) Cookie (1) Custom Metadata (1) Custom Object (1) Customer (1) Decorator Design Pattern (1) Dev Hub (1) Devops (1) Diwali (1) Email (1) FSC (1) Function (1) Goals (1) Guide (1) Household (1) Ideas (1) Improvement (1) KPIs (1) Kitchener User Group (1) Large Data Volume (1) LastModifiedDate (1) Lightning Web Component (1) Manual Sharing (1) Metrics (1) New (1) OOPS (1) OWD (1) Omni-Channel (1) Partner (1) Person Account (1) Photo (1) Platform Developer I (1) Presentation (1) Product Schedule (1) Profile (1) Promise (1) Prototype (1) Public Site (1) Query Plan (1) QuickReference (1) Reports (1) Retrieve (1) Role Hierarchy (1) SFDX (1) Salesforce Optimizer (1) Session (1) Sharing Rule (1) Sharing Sets (1) Site (1) Skills (1) Snap-ins (1) Spring 17 (1) Summer14 (1) Summer16 (1) Switch (1) SystemModStamp (1) User License (1) Users (1) Webservice (1) Winter'15 (1) Winter'17 (1) access (1) agile (1) app (1) approval process (1) aura (1) awesome (1) backup (1) bitbucket (1) book (1) campaign (1) change set (1) code (1) code coverage (1) configuration (1) csv (1) custom button (1) custom settings (1) customization (1) data loader (1) database (1) delegate Admin (1) describe (1) dom (1) dreamforce (1) duplicate (1) dynamic (1) equals (1) error (1) field-level security (1) folder (1) ftp (1) generic (1) gift (1) global describe (1) hashcode (1) import wizard (1) jenkins (1) keynote (1) long running requests (1) monitoring (1) mysql (1) page layout (1) personal (1) power of one (1) record type (1) relationship (1) request (1) review (1) sub-tab (1) tab (1) username (1) visual workflow (1) workflow (1)

Total Subscribers

Total Pageviews