You need to sign in to do that
Don't have an account?

How to test CRUD Security and FLS despite implicit describe caching?
In preparation for the Force.com AppExchange Security Review (see e.g. Requirements Checklist) I have been trying to write unit tests for my application's CRUD security and FLS logic.
The two tests below demonstrate the problem that I have got stuck on. System.runAs can have an impact on the describe call result as isUpdateable is false in the first test class and true in the second. But the first obtained describe data remains cached both within a test method and across the whole test class.
I'm looking for suggestions on how to write CRUD security and FLS tests given this unexpected behavior.
Thanks, Keith
@isTest private class DescribeFalseTest { @isTest static void testOne() { // Observed bizarre behavior: if first call is false rest will be false System.runAs(readOnlyUser()) { System.assertEquals(false, Account.SObjectType.getDescribe().isUpdateable()); } System.assertEquals(false, Account.SObjectType.getDescribe().isUpdateable()); } @isTest static void testTwo() { System.assertEquals(false, Account.SObjectType.getDescribe().isUpdateable()); System.runAs(readOnlyUser()) { System.assertEquals(false, Account.SObjectType.getDescribe().isUpdateable()); } } private static User readOnlyUser() { Profile p = [select Id, Name from Profile where Name = 'Read Only']; User u = new User( UserName = 'test-user@test-company.com', FirstName = 'Test-First-Name', LastName = 'Test-Last-Name', Alias = 'test', Email = 'test-user@test-company.com', EmailEncodingKey = 'UTF-8', LanguageLocaleKey = 'en_US', LocalesIdKey = 'en_US', TimezonesIdKey = 'America/Los_Angeles', ProfileId = p.Id ); insert u; return u; } }
@isTest private class DescribeTrueTest { @isTest static void testOne() { // Observed bizarre behavior: if first call is true rest will be true System.assertEquals(true, Account.SObjectType.getDescribe().isUpdateable()); System.runAs(readOnlyUser()) { System.assertEquals(true, Account.SObjectType.getDescribe().isUpdateable()); } } @isTest static void testTwo() { System.runAs(readOnlyUser()) { System.assertEquals(true, Account.SObjectType.getDescribe().isUpdateable()); } System.assertEquals(true, Account.SObjectType.getDescribe().isUpdateable()); } private static User readOnlyUser() { Profile p = [select Id, Name from Profile where Name = 'Read Only']; User u = new User( UserName = 'test-user@test-company.com', FirstName = 'Test-First-Name', LastName = 'Test-Last-Name', Alias = 'test', Email = 'test-user@test-company.com', EmailEncodingKey = 'UTF-8', LanguageLocaleKey = 'en_US', LocalesIdKey = 'en_US', TimezonesIdKey = 'America/Los_Angeles', ProfileId = p.Id ); insert u; return u; } }
Two follow ons to this:
Hi Keith,
We’d be happy to help you with this and thanks for logging the issues you came across. We are actively investigating them and working on a solution. Please email securecloud .at. salesforce.com if you would like to correspond with the team directly in the future.
Hi Keith,
That's indeed a bug. It's filed and we're working to resolve it. It seems to cache across different test methods and classes so I don't see an easy workaround.
-Brian Soby
Brian,
Do you now have a plan for when a fix for this should be rolled out?
Keith
Hi Keith,
We hope to resolve it as soon as possible but don't have a fixed date available.
-Brian Soby
Any update on the rollout?
Thanks,
Keith
Sorry to resurrect an old post but I have just smacked into the same problem. Is there any solution on the horizon ?
thanks,
Liam
Are you sure your situation isn't different. I'm not seeing this problem anymore.
My symptoms are the same. Here is the code I'm using
I have the same code in a separate class but with a separate profile. Each profile has different access to the field. If I run the classes individually they work fine. If I put both methods in the same class or run the classes together then one of them will fail.
I have a case with premier support so I'm hoping for some kind of resolution but I wondered if anyone had found a workaround.
Thanks,
Liam
Ah, I see the difference. You're looking at the fields, and the original poster was just getting the describes on the sobjects.
This is a bug. Do you have a case ID for your case with support?
It's case # 05320459.
Thanks,
Liam