In spring13, I am getting UNABLE_TO_LOCK_ROW error in my few test classes while running all test classes in new view provided in spring13 release. But in winter12 I don't get any error like this. Do I have to do anything to make it work? Any Thoughts?
I have gotten this error before this release. In our particular scenario, the organization had a pre-existing Custom Setting that essentially held an auto-incrementing number as an external ID for an account. The reason this error would happen every so often is due to the fact that some of the unit tests were old and using the old API. The problem came when these tests ran asynchronously and would both attempt to update this Custom Setting at the same time. This would cause the UNABLE_TO_LOCK_ROW error you are seeing since one class already had the DB lock on it. To fix this particular issue, we updated the old tests to properly create their own instance of the Custom Setting.
The error was rather strange to figure out, because just as you are seeing, the tests were very random in that they would work sometimes and other times they would fail dramatically.
Now, the scenario I outlined above is only one instance. This type of error can be thrown when two classes try to update any of the same object. If you have old code that both pull a contact from the DB for instance for testing, they can fail because of this same issue.
To fix this issue you need to go through your failing unit tests and make sure none of them use existing data from the database. You should be recreating the data model every time a test runs. It is highly inefficient, but it is the best practice for now until mocks are introduced (I am hoping those come as soon as possible). So, just make sure you never expect data in the database. Always create your own within the context of your unit test.
I've run into this as well in the past. When run individually the test classes all pass, but when run in parallel they fail.
Jesse's answer is a better long term option as it will resolve the underlying issue.
As a short term fix you can Disable Parallel Apex Testing.
Your Name > Setup > Develop > Apex Test Execution > Options: Disable Parallel Apex Testing
Update Summer '17
The Summer '17 release (v40.0) adds a new
isParallel=true annotation to @isTest that provides the bypass for disabled parallel testing to enable it on a test class by test class basis again.
@isTest(isParallel=true)annotation to indicate test classes that can be run in parallel and aren’t restricted by the default limits on the number of concurrent tests. This makes the execution of test classes more efficient, because more tests can be run in parallel.
This annotation overrides settings that disable parallel testing by default. A test class that doesn’t have this annotation is restricted by the default limits on the number of concurrent tests.
Note that I attempted to use
@IsTest(isParallel=false) in a pre-release org. It didn't appear to work. Source
Update on Update Summer '17
From the Release Notes Changes 10th May 2017
Withdrawn New Option for Parallel Testing on the isTest() Annotation The
isParalleloption on the
isTest()annotation is not available in this release. The release note about the option was removed.
Update on Update Winter '18
Run Parallel Tests Using a New Option on the @isTest Annotation is back in Winter '18.
I've also added the idea Parallel Tests Option (isParallel) on the @IsTest Annotation to exclude tests.
We also face the same issue time to time. We pinpointed our error to inserting test users in Unit Test Classes. Since we are copying the Test User data from class to class, user names of those test user are same across different classes, and when these test classes execute in parallel, inserting two users with same user name was causing the issue. We were able to fix our test classes once we adjusted the user name.
This is from documentation . Probable cause -
- When tests update the same records at the same time. Updating the same records typically occurs when tests don’t create their own data and turn off data isolation to access the organization’s data.
- When a deadlock occurs in tests that are running in parallel and that try to create records with duplicate index field values. Test data is rolled back when a test method finishes execution. A deadlock occurs when two running tests are waiting for each other to roll back data, which happens if two tests insert records with the same unique index field values in different orders.
Try running it with "Disbale Parallel Running" in Options as true. It will work