FAQ

Why does my test fail with “No such column ‘Foo__c’ on entity ‘Bar’” when the field exists in force-app?

Custom fields are loaded into the schema, but Salesforce field-level security (FLS) still applies. By default, aer test runs as a user with the System Administrator profile, which does not automatically grant access to custom objects or custom fields. SOQL queries that reference them fail just as they would in a real org without explicit permissions.

Grant the appropriate permissions to the test user with --assign-perms:

aer test force-app --assign-perms My_Permission_Set

The argument is the developer name of a permission set in your source tree (e.g., force-app/main/default/permissionsets/My_Permission_Set.permissionset-meta.xml). The flag is repeatable; pass each permission set the suite needs:

aer test force-app \
  --assign-perms My_Permission_Set \
  --assign-perms Admin_Extras

For permission sets in a managed package, load the package and qualify the name with the namespace prefix:

aer test force-app \
  --package mypkg.pkg \
  --assign-perms mypkg__Admin

Longer term, consider updating your tests to use System.runAs to execute the tests as a user explicitly granted the necessary permissions.

Permission set groups are assigned the same way with --assign-psg, which takes a group’s DeveloperName or NamespacePrefix__DeveloperName:

aer test force-app --assign-psg Sales_Users

How do I avoid repeating the same flags on every run?

Put them in an .aerrc file. aer reads ~/.config/aer/aerrc, ~/.aerrc, and ./.aerrc, in that order of increasing precedence, and applies one flag per line to the invoked command before your own arguments:

--package-dir packages
--assign-perms My_Permission_Set

A flag that is not valid for the command being run is ignored, so one file can hold defaults for test, exec, and server. Set AER_NO_RC to skip the files for a run. See Configuration for details.

Why does my multi-select picklist test pass in my org but fail in aer?

The stored order of the selections probably differs. When a record is saved, Salesforce reorders multi-select picklist selections into the order the picklist values were originally created, as described in Multi-Select Picklist Value ordering behavior. Re-ordering values in Setup changes only the order shown on records and reports; SOQL, Apex, and the API keep returning the original creation order.

aer applies the same reorder, using the order values appear in your source metadata’s value-set definition, i.e. the creation order of an org built freshly from that metadata. But creation order in a long-lived org is not exposed anywhere: retrieved metadata and describe results both report the current Setup order. If your field’s values were ever re-arranged in Setup, the order in your source metadata no longer matches the order your org stores, and aer cannot know the difference.

So a test like this can pass in your org but fail in aer (or the reverse):

My_Object__c record = new My_Object__c();
record.Colors__c = 'Green;Red';
insert record;
// Passes in an org where the Red value was created before Green; fails in
// aer if the source metadata lists Green first, because aer stores
// 'Green;Red' — its creation order for the field.
System.assertEquals('Red;Green',
	[SELECT Colors__c FROM My_Object__c WHERE Id = :record.Id].Colors__c);

To write a test that passes in both, and that survives your org’s picklist history changing, don’t assert the exact string. Split the stored value and compare sets of selections instead:

My_Object__c record = new My_Object__c();
record.Colors__c = 'Green;Red';
insert record;
My_Object__c stored = [SELECT Colors__c FROM My_Object__c WHERE Id = :record.Id];
System.assertEquals(new Set<String>{'Red', 'Green'},
	new Set<String>(stored.Colors__c.split(';')));

Set equality ignores order, so the assertion checks what was selected rather than the order Salesforce happened to store it in.