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.


  • 1
    It's my belief that unit tests in salesforce generally have negative return on time investment and Salesforce as a platform would be considerably more valuable without enforcing code coverage. – Brad Thomas Nov 19 '14 at 19:21

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:

static void TestAccountInserter()

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.


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.

  • As always, a detailed and informative answer, +1 – Phil Hawthorn Jan 14 '14 at 14:50
  • Where did you get this factoid from? "Salesforce handles over 1,000,000,000 transactions per day" – Sam Kamensky May 17 '19 at 17:19
  • 1
    @SamKamensky From salesforce.com itself. There used to be a page where you could view the number of transactions handled daily, but I can't seem to find it now. Salesforce has consistently been over 1 billion transactions per day most days (except possibly weekends) since 2013. There was a lot of media attention in the tech industry back then. A more recent article stated that a typical weekday sees more than 1.3 billion transactions daily. – sfdcfox May 17 '19 at 17:30

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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