Unit Test data accessability

Question

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?

Answer 1

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.

@TestSetup
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.startTest();
        // test the method itself
    Test.stopTest();

    // 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:

• Isolation of Test Data from Organization Data in Unit Tests
• TestSetup Annotation
• Common Test Utility Classes for Test Data Creation
• Why Are Data Silos Important in Unit Tests?

Answer 2

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

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