進行状況の追跡を始めよう
Trailhead のホーム
Trailhead のホーム

Write Permission-Based Tests

Learning Objectives

After completing this unit, you’ll be able to:

  • Explain the importance of permission-based testing.
  • Write permissions-based unit tests.

The Pattern

Many developers are positive that you should write permission tests for your code. This video offers an introduction to permission-based testing.


Permission-based testing can be the most complex testing pattern of all. In part, that’s because permissions can be confusing, and in part it’s because a good set of permissions tests uses both positive and negative test patterns. To write a permissions test, you need to generate not only test data, but also one or more test users. Once you have those, you can write both positive and negative tests and run them as your test users with or without specific permissions. 

Let’s take a look at the pattern for permissions tests.

Permissions testing Pattern

  1. Generate or load your test data.
  2. Create users with appropriate profiles or permission sets.
  3. Call Test.startTest();
  4. Start a System.runAs(user) block.
  5. If you’re writing a negative permission test:
    • Create a Boolean variable and set it to false.
  6. Start a try/catch block.
  7. Execute your code.
  8. If you’re writing a negative permission test, catch the expected exception, and if the details match, set the Boolean variable to true.
  9. Make assertions about the value or status of fields, objects, and caught exceptions to ensure the code you tested is behaving as expected.

You can test for three main types of permission: ownership, profile, and permission sets. Of the three, tests using permission sets are the trickiest, so let's look at what one of those looks like. 

This is the one case where you do not need to create your own test data. For these tests, you rely on existing permission set records. If you think about it, a permission set is a record detailing which permissions are granted. These permission set records are effectively metadata and not data. As such, you can’t create them via code, which means you can’t create a new permission set within your test. However, logically, if you are testing permission sets, you’ve already created the permission set. Thus, you only need to create a test user and assign the permission set to that user. 

The package you installed in unit 1 of this module contains a permission set called Private_Object_Access and a custom object whose default sharing is set to private. With that in place, let's look at what a permission-set test looks like. 

  1. Click Setup icon  and select Developer Console.
  2. Select File > New > Apex Class.
  3. Name the new class Permissions_Tests.
  4. Replace the contents of the class with the following code.
    @isTest
    private class Permissions_Tests {
      @TestSetup
      static void testSetup(){
        Account a = TestFactory.getAccount('No view For You!', true);
        Private_Object__c po = new Private_Object__c(account__c = a.id, notes__c = 'foo');
        insert po;
      }
      @isTest static void PermissionSetTest_Negative() {
        User u = TestFactory.generateUser('standard user');
        System.runAs(u){
          Private_Object__c[] pos;
          Test.startTest();
          pos = [SELECT Id, Account__c, notes__c FROM Private_Object__c];
          Test.stopTest();
          system.assert(pos.size() == 0, 'a user without the permission set not see any records');
        }
      }
    }
  5. Click File > Save, then Test > New Run.
  6. Select Permissions_Tests, then select PermissionSetTest_Negative.
  7. Click Run.

Code Highlights

The test methods in our code above demonstrate two things: First, that users without the permission set cannot see the Private_Object__c records. Second, that users who do have the permission set assigned can see those records. 

In our @TestSetup method, we’re creating the Private_Object__c record associated with an account. Because the sharing model is set to private, only the system can see this record. When we execute the actual test method, we create a new user and execute the query as that user. That results in the new user being unable to see the Private_object__c record.