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
crop1645crop1645 

Winter 13 anomaly - Test runs using Force.com Run Tests UI but fails using Eclipse Apex Test Runner

Winter 13 anomaly 

 

I have a test class Foo that among other things:

 

* inserts a ContentVersion

* inserts a ContentWorkspaceDoc

* updates the ContentVersion with custom field values and tags

 

If I login to the Winter13 sandbox using credentials for system administrator X, select class Foo and Run Tests - the tests pass fine

 

If I use Ecliipse IDE Version 24.0.0.201202291629 also logged in as user X and do Apex Test Runner on the very same class Foo, I get the error:

System.DmlException: Update failed. First exception on row 0 with id 068V00000008ILuIAM; first error: INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY, insufficient access rights on cross-reference id: []

 

where the ID is the ID of the ContentVersion record and the DML is on the Update of the ContentVersion record

 

These tests all ran fine in Eclipse prior to the sandbox being upgraded to Winter 13

 

Here's what I don't get:

Doesn't Eclipse IDE simply instruct the sandbox cloud to execute the test class Foo, all execution occurs in the sandbox cloud, and the results/log are merely passed back to Eclipse?

 

Given that the Ecliipse project uses the same credentials as those I use to UI login to the Force.com platform, the Eclipse test execution should execute the same as running the test via a Force.com Run Tests button click. True?

 

What could be different here? Does the Winter 13 sandbox code somehow execute the test class submitted by Eclipse with different context than when I execute it from the Force.com UI?  I've never seen this before and I've been running this APEX class in Eclipse successfully since V19.0

 

Best Answer chosen by Admin (Salesforce Developers) 
crop1645crop1645

For both my orgs broken by Winter 13  doing Eclipse testing.

 

Org 1 - Insufficient access on cross reference id doing an update to ContentVersion

 

Resolved by SFDC update to my Winter 13 sandbox

 

Org 2 was a heavy user of custom settings; the getAll() and get() fix + V24 resolved it.

 

I retrograded to V20.0, reran in Eclipse, and problem resolved by SFDC update to my Winter 13 sandbox

All Answers

cropzimcropzim

OK, here is more info ...

 

If the test class creates or updates Custom Settings, then when executed via Apex Run Tests in Eclipse IDE, the custom settings new values are not available to the rest of the test method.

 

If you execute the very same test class in the Force.com UI 'Run Tests' button, the custom settings new values are available to the rest of the test method

LiamCoLiamCo

 

The same or similar issue occurs when running tests from the Force.com migration tool.

 

http://boards.developerforce.com/t5/Apex-Code-Development/Custom-Settings-method-return-wrong-values-when-called-from/m-p/500463#M92663

 

I also have a case raised, I will update with any further information. In my experience, running tests has got definite issues with user contexts. I had a problem with using runAs in tests that never got fixed to my knowledge.

 

http://boards.developerforce.com/t5/Apex-Code-Development/How-to-test-CRUD-Security-and-FLS-despite-implicit-describe/td-p/186215

 

I raised a case but as far as I know this was never fixed.

 

I've linked this back to my post to complete the circular reference.

 

crop1645crop1645

Just got off phone with developer support

 

1. Reproduced problem to their satisfaction

 

2. Also did experiments by changing the Version of the APEX class:

 

Rerun test in Eclipse:

V20.0 - fails

V23.0 - fails

V24.0 - succeeds

V25.0 - succeeds

V26.0 - succeeds

 

So, another Eclipse IDE workaround is to upgrade the affected classes to Version 24.0+ . This may require adding @isTest(SeeAllData=true) as your test classes may depend on existing records (like Pricebooks,  <reference tables>, or Custom Settings). See SFDC doc here.

sspopovichsspopovich

Any updates on this issue?  I'm also seeing it in Winter '13 sandboxes, but I'm finding that the workaround of updating to v24 and up doesn't work, even after I've updated all of the Apex (classes and triggers) in the org to v24.  However, running the tests from the Web page, rather than from Eclipse, does still work.  Is there a particular version of Eclipse that's required for tests to work with Winter '13?  The last I'd heard, versions later than Helios weren't "officially supported" by Salesforce, and when I look at http://wiki.developerforce.com/page/Force.com_IDE_Installation, there still don't seem to be any instructions for installing the IDE posted on the site by Salesforce after 3.6 (Helios), so I've assumed that that means that we're not supposed to be using later versions and I've stayed on Helios for Salesforce, even though it's been getting more and more obsolete as new versions have been released over the last few years.

crop1645crop1645

Yes, the update to V24+ only worked in limited scenarios.  For example, I discovered that

 

  • If you had a custom setting, in some circumstances, the getInstance method would not locate the Custom Setting - even though you had just inserted it.  This seemed to be true of custom settings that you had inserted as part of the testmethod.  At one point, I thought it might be that all classes in the executionpath that referneced the custom setting had to be at V24.0+
  • This was only true when using Eclipse;  running tests from the Force.com UI always worked.
  • I could work around this by using a combination ofthe Custom Setting getAll() method followed by a normal Map method get(). getAll() always returned the custom settings (all of them - even the ones I inserted)

I'm not aware of anything more re: Helios than you are. I'm using Helios Service Release 1 and have been for some months now

 

There has been no update from SFDC dev support yet once they accepted the case.

sspopovichsspopovich

Thanks, Eric, for the reply...although here I have no Custom Settings being referenced in the code that I can find, and no getInstance or getAll calls in any of the Apex code in that particular org.  I do have to resist the urge to curse under my breath every time I see that non-specific error message about insufficient access, which could at least provide the ID of the object to which Salesforce thinks the code doesn't have access, but doesn't happen to do so; so I have no good way of knowing which of the objects in the batch that fails caused the issue without totally "unbatchifying" the Apex code, much less which of the multiple cross-reference IDs in each of the objects Salesforce thinks that the code doesn't have access rights to see...and of course the objects in the code are all being created as part of the unit testing process, so none of the IDs that I do see in the debug log even exist once the test is complete, for me to check what access it might somehow be missing.  Did you overcome similar difficulties in debugging your issue thus far?

crop1645crop1645

sspopovich:

 

Ah, yes, I had two orgs, each broken by Winter 13  doing Eclipse testing.

 

Org 1 - as originally reported in the post, it was Insufficient access on cross reference id doing an update to ContentVersion

 

I never figured this out. My test was using a controller so I knew what record was affected but I could not for the life of me figure out which ID field was violating the constraint

 

Org 2 was a heavy user of custom settings; the getAll() and get() fix + V24 resolved it.

 

Rather than unbatchify your code, can you replace your DML call with Database.update (or Database.insert as appropriate? Then, you will get a list of results that will tell you which row is in error (although not why a constraint is violated).  As you suspect, some context is passed by Eclipse to the cloud when the class is executed that is different than the context used when running the test in the Force.com UI.

 

The package.xml contains the version, as does each class.  I don't know what else besides the user could be different (Eclipse logs in with user defined in the project settings; when you run the Force.com UI Run Test, you might be logged in as a different user)

 

kibitzerkibitzer

It looks like this bug applies to package deployments as well when SeeAllData is true.

kibitzerkibitzer

It looks like the problem has been resolved. I've done further testing on a Winter 13 sandbox and the code that previously failed is now working correctly (including package installation).

crop1645crop1645

For both my orgs broken by Winter 13  doing Eclipse testing.

 

Org 1 - Insufficient access on cross reference id doing an update to ContentVersion

 

Resolved by SFDC update to my Winter 13 sandbox

 

Org 2 was a heavy user of custom settings; the getAll() and get() fix + V24 resolved it.

 

I retrograded to V20.0, reran in Eclipse, and problem resolved by SFDC update to my Winter 13 sandbox

This was selected as the best answer
kibitzerkibitzer

I was very glad they resolved it. But to be honest - I did find it somewhat scary that they were still dealing with what I perceived to be critical bugs just days before release.