A blog dedicated to Salesforce Ohana

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:

2 comments:

Follow Me

Enter your email address:

Delivered by FeedBurner

Popular Posts

Labels

Salesforce (99) Apex (43) admin (27) ADM (20) visualforce (20) dev 501 (19) integration (18) learn salesforce (17) 501 (16) SOAP (13) tutorial (11) Certification. (9) lightning (8) Trigger (7) test class (7) unit testing (7) design pattern (6) report (6) security (6) trailhead (6) Advanced Admin (5) New Features (5) SOQL (5) css (5) dashboard (5) debug (5) developer (5) formula (5) javascript (5) mobile (5) salesforce release (5) service cloud (5) solution management (5) use case (5) JSON (4) Lightning Experience (4) WebSphere (4) best practice (4) cast iron (4) component (4) github (4) html (4) polymer (4) profiles (4) responsive (4) tdd (4) ui (4) Certification (3) Live Chat (3) Performance (3) Products (3) Sales Cloud (3) Study Notes. (3) Summer15 (3) Tips (3) deployment (3) dynamic apex (3) event (3) license (3) map (3) mapbox (3) singleton (3) version controlling (3) Advanced Apex (2) Bulkify (2) Data Architecture and Management Certification (2) Distributed Version Controlling (2) Eclipse (2) Einstein (2) Force.com IDE (2) Governor Limit (2) IBM (2) Kitchener Developer Group (2) Lightning Design System (2) Live Agent (2) Online Event (2) Price Book (2) REST (2) SOSL (2) Spring 15 (2) Summer17 (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) permission (2) process builder (2) release (2) salesforce1 (2) strategy (2) xml (2) Agent Productivity (1) Analytics (1) Architect (1) Asynchronous callout (1) Bots (1) Browser (1) Bulk data load (1) CTA (1) Calendar (1) Canon (1) Case Management (1) Classic (1) Contact Center (1) Continuation (1) Continuous Integration (1) Cookie (1) Custom Metadata (1) Custom Object (1) Decorator Design Pattern (1) Diwali (1) Email (1) FSC (1) Financial Services Cloud (1) Goals (1) Groups (1) Guide (1) Household (1) Ideas (1) Implicit Sharing (1) Improvement (1) JourneyToCTA (1) KPIs (1) Kitchener User Group (1) Large Data Volume (1) LastModifiedDate (1) Metadata (1) Metrics (1) Omni-Channel (1) Opportunity (1) Person Account (1) Photo (1) Platform Developer I (1) Presentation (1) Product Schedule (1) Profile (1) Public Site (1) Query Plan (1) QuickReference (1) Reports (1) Role (1) SFDX (1) Salesforce DX (1) Salesforce Optimizer (1) Scratch Org (1) Session (1) Sharing (1) Site (1) Skills (1) Snap-ins (1) Spring 17 (1) Summer14 (1) Summer16 (1) Switch (1) SystemModStamp (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) object (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