Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

This might be a silly question, but I am new to Salesforce, so I am asking this question that why there is 75% code coverage concept is there in salesforce?

What I know, in order to deploy or create a package 75% code coverage is mandetory.

But why this percenatge concept is a very improtant aspect in salesforce.

Regards

share|improve this question

3 Answers 3

Here's my take on it.

Salesforce is 'multi-tenant' meaning that lots of companies and their users are hosted on the same physical platform as one-another. That being the case, its important that any custom code installed on the platform is robust. I believe the 75% mark is high enough to make you consider writing effective unit tests (though to be honest, it doesn't really enforce it) but not too high that you end up chasing 100% coverage when those final few %age points maybe too costly and time-consuming to achieve.

The 75% mark only really refers to test coverage, it doesn't really have anything to do with how effective your tests are, for example you may have a really bad test that does achieve 100% coverage. Consider this basic fictitious class whose job it is simply to create an Account called 'One'.

public class AccountInserter()
{
    public static void insertAccount()
    {
        insert new Account(Name='One');
    }
}

Then, you could write a test which would give you 100% coverage:

@isTest
static void TestAccountInserter()
{
    AccountInserter.insertAccount();
}

But, what is this actually testing? Sure, it gets you the coverage but really to prove that the test worked, you would need to check that the Account was actually created - in code, i.e. by re-querying the results back from Salesforce and using System.assert you could really ensure that the Account One was created.

I would think you'll get quite a few answers on this subject, but in summary I feel that the 75% lower limit enforces you to put a reasonable amount of effort into your unit tests.

share|improve this answer
    
nice explanation –  SFDC Geek Jan 14 at 14:26
1  
Salesforce also uses production unit tests to test out their framework releases. Heres a nice blog that describes it blogs.developerforce.com/engineering/2013/05/… –  BarCotter Jan 14 at 14:33
    
Good point @BarCotter, there are a few aspects which could be added to my answer –  Phil Hawthorn Jan 14 at 14:35
2  
Just to add a bit more info to Phil's answer : if you use the Force.com Code Scanner here (security.force.com/security/tools/forcecom/scanner), it will actually look for quality in your tests : at least it will flag tests which have no System.Assert calls. –  altius_rup Jan 19 at 23:34

Unit testing is designed to help catch logic flaws. By writing unit tests, you will uncover bugs that won't be apparent during compilation time but might cause your code to work incorrectly when a user attempts to run it. Forcing 75% coverage requires the developer to think about their code a second time, double-checking their work. If you can't write the unit test, then that means you don't understand the logic, or the code is flawed. Either situation is undesirable.

Of course, unit testing without "assert" functions (actually checking the output to match expected values) makes unit testing less valuable, but they likely decided that this would be arbitrary and not as useful as code coverage; if they had simply insisted that you write, for example, five asserts per test method, you'd be forced to come up with arbitrarily useless asserts for your code (most test methods don't necessarily check five outputs).

While it is true that you can write useless unit tests, covering all the possible branches of code (at least 75% of them) makes it more likely that you'll find a regression bug if you later change that code. The 75% marker was specifically selected to imply a certain bit of a limitation of the platform: 100% coverage should be impossible to test, because the unit testing language does not allow to test exceptions, etc, that can be arbitrarily difficult to test normally.

In all but the most simple code, 90% coverage should be the value you look to achieve, being that 100% is usually nearly impossible, and 75% is the minimum, so you want some "breathing room" for deployment; you have to write the unit tests after the code you're testing, unlike some systems, where you write the unit tests first then make code that meets the test.

Salesforce is a platform that requires performance, since any code that is bloated or slows down the system for one user affects the user experience for all users as a whole (there is only so much server capacity to process requests). Salesforce handles over 1,000,000,000 transactions per day, no simple feat, and it requires a lot of hardware. Unit tests help make sure that your code is functioning within normal parameters to help give a better experience for everyone.

share|improve this answer
    
As always, a detailed and informative answer, +1 –  Phil Hawthorn Jan 14 at 14:50

Also, let's not forget that apart from your code, logic can also be introduced in the system by other people like your administrator.

Administrators could be introducing new validation rules, workflows, required fields etc that could potentially break your code. Having these unit tests allows both you and your administrator to run these unit tests every time new logic is introduced so you can rest assured that the things you previously built don't break because of this new logic.

I would give this to you as a best practice to realy make a habit of running these unit test on a regular base. It's MUCH easier to fix issues introduced by new logic at the time you introduce this new logic than having to plough through a list of changes from several weeks that could have broken your code.

Doing this will also make sure that it's YOU that noticed the broken code and not your end users.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.