function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
MarceldeBMarceldeB 

Running parallel tests in spring '12 fails

Hi,

since the upgrade to spring'12 many of my tests fail if I run them from theApex Test Execution page. But if I run them from the Apex Classes page (run all tests) they all pass fine!

 

It looks like the way the system processes simultanious tests in teh Test Execution Page has been changed. In the failing scripts I first delete all instances of a custom object and then insert a new instance, to be sure only that instance is in the database while testing. The error message I get since this week in many of my testclasses is:

 

System.DmlException: Delete failed. First exception on row 0 with id a03A0000001ItxxIAC; first error: UNABLE_TO_LOCK_ROW, unable to obtain exclusive access to this record: []

 

Any tricks/ explanation or comment from salesforce?

thanks.

jbowesjbowes

MarceldeB, did you find a solution to this? It's annoying me, too. I have a similar situation to yours with some custom settings records used in tests. I had the creation of the records in a method that my test classes were calling, but they're stepping all over each other trying to delete each others' test data. I attempted using a static variable to keep them from doing this, and also attempted to use something approximating a singleton, but it's not helping.

craigmhcraigmh

Spring '12 prevents you from using the data in your instance by default.

 

More details:

http://stackoverflow.com/questions/9164986/how-do-i-avoid-standard-price-not-defined-when-unit-testing-an-opportunitylineit

jbowesjbowes

True, but this is a different situation from that. If you have a bunch of tests running in parallel they may all try to access the same *test* data (not regular org data), and there may be failures as described above.

 

In my situation, for example, I am inserting custom settings records with different settings to test different configurations regardless of the org configuration. The settings always have the same name, which is how they are accessed (via getInstance or getValues), and there are collisions happening between the different tests.

craigmhcraigmh

Hehe, sorry. I was in copy/paste mode on all these topics as a result of that change they made.

 

Have you thought about using the FOR UPDATE keywords? They work with delete statements, although I'm not sure if the resulting behavior would work in your situation.

http://www.salesforce.com/us/developer/docs/apexcode/Content/langCon_apex_locking_statements.htm

BBeairdBBeaird

I'm having the exact same issue. All my test classes are using API 24.0 and several are sharing test data generation methods. I thought this was the best practice?? What's the point of offering public test generation methods if the tests will just step all over each other using it?

 

If I change the option so that tests are not run in parallel, I get no errors. Am I missing something here or does this defeat the entire purpose of a public test data generation method?

josh bowesjosh bowes

I never found a complete solution to this. I did see some improvement by accessing my test data via classes that are singleton-ish. The test data are available as attributes on those classes. That got almost all of my tests passing in parallel most of the time. They still don't all work if I use API 24 for everything, though. It might be worth trying an earlier API version if possible to see if that helps.

 

 

BBeairdBBeaird

I guess it's not that big of a deal since they pass using the traditional "run all" method. For now, I just don't run them in parallel if running multiple from the Test Execution page.

admintrmpadmintrmp
I've noticed this issue now that we are on Spring '13 (API 27.0).

I have two @future methods that are running parallel and kill each other off. I disabled parallel testing and it now works. My annoyance is the fact that parallel testing was quicker.

I presume that installing the package into an organization would follow the traditional test process (fingers crossed).