Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
Are your tests relying on data that exists in the environment? @seeAllData=true or API version below 24? You should aim at making the test data in the test itself, even if it's a test that uses System.runAs(user u)... What happens if you run them all from Eclipse? Might be something nasty to do with server load/parallel execution. – eyescream Feb 5 '13 at 9:56
When I run test classes separately which gave me error while running all tests together now they pass. – doga Feb 5 '13 at 10:07
up vote 15 down vote accepted

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.

share|improve this answer
... and if you really really have to rely on existing data - at least use [SELECT ... FOR UPDATE] ;) – eyescream Feb 5 '13 at 17:55
We are getting this too. Sometimes we can't or don't want to create our own data (that seeAllData attribute is there for a reason). Using locking (FOR UPDATE) works for a couple tests, but if you have several tests running at once that access the same records, it is still a problem. I guess there's no way to have a test not run in parallel with others? – Rob Scott Feb 6 '13 at 20:02
@RobScott - You can run them synchronously from the Apex Test Executioner. When you deploy it should be synchronous. See page 110 of the Spring '13 Release Notes. Still, if someone in the org does something at the same time as the unit test it could be an issue, I suppose. – Peter Knolle Feb 15 '13 at 2:21
I'm seeing this also with custom settings, but with tests that are marked SeeAllData=false. Surely these should be isolated from each other? – Richard Corfield Aug 23 '13 at 9:54

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

share|improve this answer
Will this also stop asynchronous unit tests from running when you do a deploy? As far as I know, all unit tests run asynchronously during a deploy no matter what you do. – Jesse Altman Feb 15 '13 at 3:12
@JesseAltman You can still run the test cases asynchronously, but they will run one at a time. By default I think two tests run in parallel with asynchronous testing, which is where the issue occurs. – Daniel Ballinger Feb 15 '13 at 7:39
@JesseAltman - When the tests run on a production deploy they should still run synchronously. See page 110 of the Spring '13 release notes: All tests started through the Salesforce user interface now run asynchronously. Tests that are run as part of a deployment, a package install, or a package upload still run synchronously. – Peter Knolle Feb 15 '13 at 16:46

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.

Hope this helps.

share|improve this answer

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

share|improve this answer

Your Answer


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.