UNABLE_TO_LOCK_ROW error while running all apex test classes

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.

See New Option for Parallel Testing on the isTest() Annotation

Use the @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 isParallel option 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.

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.

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.