Today I experienced an error that I have never experienced before. When I go into my developer console on salesforce and run unit tests for, supposedly, all of my code, I get my typical high percentage overall coverage as a result. The reason I was running a complete unit test is because I added one simple class to a package, which had a corresponding test class that covered the code entirely.

I had previously released the package with a passing score, which I assume was significantly higher than 75%. Yet, today, when I was going to publish the package after seeing the overall coverage was high, I kept getting the error:

Upload Failed Average test coverage across all Apex Classes and Triggers is 73%, at least 75% test coverage is required.

Never before had my code been passing all of the tests and obtaining a passing score on the overall code coverage but failed to publish.

Currently I am blaming DML errors. Some of the test classes, which I had written prior to gaining some knowledge about test classes, used (seeAllData=true). Sometimes (very rarely) my unit tests would result in a failure of a large class because of a locked row exception. I'm guessing that because some test classes seeAllData, and all test classes are inserting similar records, that is why I get this error.

Here is my question: What is the scope/accessibility (unsure of the word) of test methods?

What I mean is, if one test method inserts ExampleObject__c and another test method inserts a different ExampleObject__c (whether ExampleObject__c is an object OR custom settings) (asynchronous) could those objects possibly interact?

Is the reason for my locked row errors because two test methods are inserting the same custom setting?

If so, how do you go about making sure that the test class has the appropriate setting data but does not seeAllData/lock rows for other test methods?

  • Unable to lock row during test methods it tough to track down many times unless it truly is a lock row issue during a single transaction. Easiest way to fix it and be sure it is due to the nature of test methods is to disable parallel testing. I know not an answer as to why but more of a how to solve.
    – Eric
    Jan 4, 2017 at 23:34

2 Answers 2


Tests should run synchronously during deployments, so I do not believe row locking can explain the issues you are running into. But you should never use @SeeAllData=true, except as an absolute last resort.

You go about making sure the test has the correct settings by creating your own data! Typically with Custom Settings it makes the most sense to create this data in a @TestSetup method.

static void setup()
    insert new MySetting__c(Name='Some Config');

static testMethod void testSomeMethod()
    system.assertNotEquals(null, MySetting__c.getInstance('Some Config'),
        'The configuration should be set up.');
    // the above assertion is just to demonstrate the principle

        // test the method itself

    // assert on behavior

If you really want to make sure your app is configured correctly, you may find that Custom Metadata Types are a better fit, as you can deploy those. See also:

  • Yet row locking is the issue, it is the error that comes randomly from only a few out of all of the tests (meaning if I ran the tests 100 times, maybe 28 times there would be a row locking error). I'll keep looking into it and update you on what I find, for now the links constitute my answer. Jan 4, 2017 at 23:08

By default, all test classes' methods run in parallel and there could be a chance of locking if multiple test class's methods doing DML option on same object at same time.

To execute one test method at a time, enable this settings:

Setup--> Apex Test Execution --> Options (button) --> Disable Parallel Apex Testing

Apex Test Execution Options

Regarding, the data setup in test class using @testSetup and making (seeAllData=False), refer @Adrian's answer.

  • Disabling parallel apex testing still resulted in Locked row exceptions on rare occasions (I tested multiple times over). Also I just noted that I no longer use seeAllData, for reference. What is the difference between (seeAllData=False) and simply not including "seeAllData" at all? Jan 4, 2017 at 23:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .