Annotations
An Apex annotation modifies the way that a method or class is used, similar to annotations in Java.
Annotations are defined with an initial @ symbol, followed by the appropriate keyword. To add an annotation to a method, specify it immediately before the method or class definition. For example:
global class MyClass {
@future
Public static void myMethod(String a)
{
//long-running Apex code
}
}
Apex supports the following annotations.
· Apex REST annotations:
AuraEnabled Annotation
The @AuraEnabled annotation enables client- and server-side access to an Apex controller method. Providing this annotation makes your methods available to your Lightning components. Only methods with this annotation are exposed.
Create a server-side controller in Apex and use the @AuraEnabled annotation to enable client- and server-side access to the controller method.
Only methods that you have explicitly annotated with @AuraEnabled are exposed. Calling server-side actions aren’t counted against your org’s API limits. However, your server-side controller actions are written in Apex, and as such are subject to all the usual Apex limits.
This Apex controller contains a serverEcho action that prepends a string to the value passed in.
public with sharing class SimpleServerSideController {
//Use @AuraEnabled to enable client- and server-side access to the method
@AuraEnabled
public static String serverEcho(String firstName) {
return ('Hello from the server, ' + firstName);
}
}
In addition to using the @AuraEnabled annotation, your Apex controller must follow these requirements.
· Methods must be static and marked public or global. Non-static methods aren’t supported.
· If a method returns an object, instance methods that retrieve the value of the object’s instance field must be public.
Deprecated Annotation
Use the deprecated annotation to identify methods, classes, exceptions, enums, interfaces, or variables that can no longer be referenced in subsequent releases of the managed package in which they reside. This is useful when you are refactoring code in managed packages as the requirements evolve. New subscribers cannot see the deprecated elements, while the elements continue to function for existing subscribers and API integrations.
The following code snippet shows a deprecated method. The same syntax can be used to deprecate classes, exceptions, enums, interfaces, or variables.
@deprecated
// This method is deprecated. Use myOptimizedMethod(String a, String b) instead.
global void myMethod(String a) {
}
Note the following rules when deprecating Apex identifiers:
· Unmanaged packages cannot contain code that uses the deprecated keyword.
· When an Apex item is deprecated, all global access modifiers that reference the deprecated identifier must also be deprecated. Any global method that uses the deprecated type in its signature, either in an input argument or the method return type, must also be deprecated. A deprecated item, such as a method or a class, can still be referenced internally by the package developer.
· webService methods and variables cannot be deprecated.
· You can deprecate an enum but you cannot deprecate individual enum values.
· You can deprecate an interface but you cannot deprecate individual methods in an interface.
· You can deprecate an abstract class but you cannot deprecate individual abstract methods in an abstract class.
· You cannot remove the deprecated annotation to undeprecate something in Apex after you have released a package version where that item in Apex is deprecated.
Future Annotation
Use the future annotation to identify methods that are executed asynchronously. When you specify future, the method executes when Salesforce has available resources.
For example, you can use the future annotation when making an asynchronous Web service callout to an external service. Without the annotation, the Web service callout is made from the same thread that is executing the Apex code, and no additional processing can occur until the callout is complete (synchronous processing).
Methods with the future annotation must be static methods, and can only return a void type. The specified parameters must be primitive data types, arrays of primitive data types, or collections of primitive data types. Methods with the futureannotation cannot take sObjects or objects as arguments.
To make a method in a class execute asynchronously, define the method with the future annotation. For example:
global class MyFutureClass {
@future
static void myMethod(String a, Integer i) {
System.debug('Method called with: ' + a + ' and ' + i);
// Perform long-running code
}
}
To allow callouts in a future method, specify (callout=true). The default is (callout=false), which prevents a method from making callouts.
The following snippet shows how to specify that a method executes a callout:
@future (callout=true)
public static void doCalloutFromFuture() {
//Add code to perform callout
}
Future Method Considerations
· Remember that any method using the future annotation requires special consideration because the method does not necessarily execute in the same order it is called.
· Methods with the future annotation cannot be used in Visualforce controllers in either getMethodName or setMethodNamemethods, nor in the constructor.
· You cannot call a method annotated with future from a method that also has the future annotation. Nor can you call a trigger from an annotated method that calls another annotated method.
InvocableMethod Annotation
Use the InvocableMethod annotation to identify methods that can be run as invocable actions.
Invocable methods are called with the REST API and used to invoke a single Apex method. Invocable methods have dynamic input and output values and support describe calls.
The following code sample shows an invocable method with primitive data types.
public class AccountQueryAction {
@InvocableMethod(label='Get Account Names' description='Returns the list of account names corresponding to the specified account IDs.')
public static List<String> getAccountNames(List<ID> ids) {
List<String> accountNames = new List<String>();
List<Account> accounts = [SELECT Name FROM Account WHERE Id in :ids];
for (Account account : accounts) {
accountNames.add(account.Name);
}
return accountNames;
}
}
This code sample shows an invocable method with a specific sObject data type.
public class AccountInsertAction {
@InvocableMethod(label='Insert Accounts' description='Inserts the accounts specified and returns the IDs of the new accounts.')
public static List<ID> insertAccounts(List<Account> accounts) {
Database.SaveResult[] results = Database.insert(accounts);
List<ID> accountIds = new List<ID>();
for (Database.SaveResult result : results) {
if (result.isSuccess()) {
accountIds.add(result.getId());
}
}
return accountIds;
}
}
Invocable Method Considerations
Implementation Notes
· The invocable method must be static and public or global, and its class must be an outer class.
· Only one method in a class can have the InvocableMethod annotation.
· Triggers can’t reference invocable methods.
· Other annotations can’t be used with the InvocableMethod annotation.
Inputs and Outputs
There can be at most one input parameter and its data type must be one of the following:
· A list of a primitive data type or a list of lists of a primitive data type – the generic Object type is not supported.
· A list of an sObject type or a list of lists of an sObject type – the generic sObject type is not supported.
· A list of a user-defined type, containing variables of the supported types and with the InvocableVariable annotation. Create a custom global or public Apex class to implement your data type, and make sure your class contains at least one member variable with the invocable variable annotation.
If the return type is not Null, the data type returned by the method must be one of the following:
· A list of a primitive data type or a list of lists of a primitive data type – the generic Object type is not supported.
· A list of an sObject type or a list of lists of an sObject type – the generic sObject type is not supported.
· A list of a user-defined type, containing variables of the supported types and with the InvocableVariable annotation. Create a custom global or public Apex class to implement your data type, and make sure your class contains at least one member variable with the invocable variable annotation.
Managed Packages
· You can use invocable methods in packages, but once you add an invocable method you can’t remove it from later versions of the package.
· Public invocable methods can be referred to by flows and processes within the managed package.
· Global invocable methods can be referred to anywhere in the subscriber org. Only global invocable methods appear in the Cloud Flow Designer and Process Builder in the subscriber org.
For more information about invocable actions, see Force.com Actions Developer’s Guide.
InvocableVariable Annotation
Use the InvocableVariable annotation to identify variables used by invocable methods in custom classes.
The InvocableVariable annotation identifies a class variable used as an input or output parameter for an InvocableMethodmethod’s invocable action. If you create your own custom class to use as the input or output to an invocable method, you can annotate individual class member variables to make them available to the method.
The following code sample shows an invocable method with invocable variables.
global class ConvertLeadAction {
@InvocableMethod(label='Convert Leads')
global static List<ConvertLeadActionResult> convertLeads(List<ConvertLeadActionRequest> requests) {
List<ConvertLeadActionResult> results = new List<ConvertLeadActionResult>();
for (ConvertLeadActionRequest request : requests) {
results.add(convertLead(request));
}
return results;
}
public static ConvertLeadActionResult convertLead(ConvertLeadActionRequest request) {
Database.LeadConvert lc = new Database.LeadConvert();
lc.setLeadId(request.leadId);
lc.setConvertedStatus(request.convertedStatus);
if (request.accountId != null) {
lc.setAccountId(request.accountId);
}
if (request.contactId != null) {
lc.setContactId(request.contactId);
}
if (request.overWriteLeadSource != null && request.overWriteLeadSource) {
lc.setOverwriteLeadSource(request.overWriteLeadSource);
}
if (request.createOpportunity != null && !request.createOpportunity) {
lc.setDoNotCreateOpportunity(!request.createOpportunity);
}
if (request.opportunityName != null) {
lc.setOpportunityName(request.opportunityName);
}
if (request.ownerId != null) {
lc.setOwnerId(request.ownerId);
}
if (request.sendEmailToOwner != null && request.sendEmailToOwner) {
lc.setSendNotificationEmail(request.sendEmailToOwner);
}
Database.LeadConvertResult lcr = Database.convertLead(lc, true);
if (lcr.isSuccess()) {
ConvertLeadActionResult result = new ConvertLeadActionResult();
result.accountId = lcr.getAccountId();
result.contactId = lcr.getContactId();
result.opportunityId = lcr.getOpportunityId();
return result;
} else {
throw new ConvertLeadActionException(lcr.getErrors()[0].getMessage());
}
}
global class ConvertLeadActionRequest {
@InvocableVariable(required=true)
global ID leadId;
@InvocableVariable(required=true)
global String convertedStatus;
@InvocableVariable
global ID accountId;
@InvocableVariable
global ID contactId;
@InvocableVariable
global Boolean overWriteLeadSource;
@InvocableVariable
global Boolean createOpportunity;
@InvocableVariable
global String opportunityName;
@InvocableVariable
global ID ownerId;
@InvocableVariable
global Boolean sendEmailToOwner;
}
global class ConvertLeadActionResult {
@InvocableVariable
global ID accountId;
@InvocableVariable
global ID contactId;
@InvocableVariable
global ID opportunityId;
}
class ConvertLeadActionException extends Exception {}
}
InvocableVariable Modifiers
The invocable variable annotation has three available modifiers, as shown in this example.
@InvocableVariable(label='yourLabel' description='yourDescription' required=(true | false))
All modifiers are optional.
label
The label for the variable. The default is the variable name.
description
The description for the variable. The default is Null.
required
Whether the variable is required. If not specified, the default is false. The value is ignored for output variables.
InvocableVariable Considerations
· Other annotations can’t be used with the InvocableVariable annotation.
· Only global and public variables can be invocable variables.
· The invocable variable can’t be one of the following:
· A type such as an interface, class, or enum.
· A non-member variable such as a static or local variable.
· A property.
· A final variable.
· Protected or private.
· The data type of the invocable variable must be one of the following:
· A primitive data type or a list of a primitive data type – the generic Object type is not supported.
· An sObject type or a list of an sObject type – the generic sObject type is not supported.
· For managed packages:
· Public invocable variables can be set in flows and processes within the same managed package.
· Global invocable variables can be set anywhere in the subscriber org. Only global invocable variables appear in the Cloud Flow Designer and Process Builder in the subscriber org.
For more information about invocable actions, see Force.com Actions Developer’s Guide.
IsTest Annotation
Use the isTest annotation to define classes and methods that only contain code used for testing your application. TheisTest annotation on methods is equivalent to the testMethod keyword.
Classes defined with the isTest annotation don't count against your organization limit of 3 MB for all Apex code.
Classes and methods defined as isTest can be either private or public. Classes defined as isTest must be top-level classes.
This is an example of a private test class that contains two test methods.
@isTest
private class MyTestClass {
// Methods for testing
@isTest static void test1() {
// Implement test code
}
@isTest static void test2() {
// Implement test code
}
}
This is an example of a public test class that contains utility methods for test data creation:
@isTest
public class TestUtil {
public static void createTestAccounts() {
// Create some test accounts
}
public static void createTestContacts() {
// Create some test contacts
}
}
Classes defined as isTest can't be interfaces or enums.
Methods of a public test class can only be called from a running test, that is, a test method or code invoked by a test method, and can't be called by a non-test request.. To learn about the various ways you can run test methods
IsTest(SeeAllData=true) Annotation
For Apex code saved using Salesforce API version 24.0 and later, use the isTest(SeeAllData=true) annotation to grant test classes and individual test methods access to all data in the organization, including pre-existing data that the test didn’t create. Starting with Apex code saved using Salesforce API version 24.0, test methods don’t have access by default to pre-existing data in the organization. However, test code saved against Salesforce API version 23.0 and earlier continues to have access to all data in the organization and its data access is unchanged. See Isolation of Test Data from Organization Data in Unit Tests.
Considerations for the IsTest(SeeAllData=true) Annotation
· If a test class is defined with the isTest(SeeAllData=true) annotation, this annotation applies to all its test methods whether the test methods are defined with the @isTest annotation or the testmethod keyword.
· The isTest(SeeAllData=true) annotation is used to open up data access when applied at the class or method level. However, using isTest(SeeAllData=false) on a method doesn’t restrict organization data access for that method if the containing class has already been defined with the isTest(SeeAllData=true) annotation. In this case, the method will still have access to all the data in the organization.
This example shows how to define a test class with the isTest(SeeAllData=true) annotation. All the test methods in this class have access to all data in the organization.
Run Unit Test Methods
To verify the functionality of your Apex code, execute unit tests. You can run Apex test methods in the Developer Console, in Setup, in the Force.com IDE, or using the API.
You can run these groupings of unit tests.
· Some or all methods in a specific class
· Some or all methods in a set of classes
· A predefined suite of classes, known as a test suite
· All unit tests in your org
To run a test, use any of the following:
// All test methods in this class can access all data.
@isTest(SeeAllData=true)
public class TestDataAccessClass {
// This test accesses an existing account.
// It also creates and accesses a new test account.
static testmethod void myTestMethod1() {
// Query an existing account in the organization.
Account a = [SELECT Id, Name FROM Account WHERE Name='Acme' LIMIT 1];
System.assert(a != null);
// Create a test account based on the queried account.
Account testAccount = a.clone();
testAccount.Name = 'Acme Test';
insert testAccount;
// Query the test account that was inserted.
Account testAccount2 = [SELECT Id, Name FROM Account
WHERE Name='Acme Test' LIMIT 1];
System.assert(testAccount2 != null);
}
// Like the previous method, this test method can also access all data
// because the containing class is annotated with @isTest(SeeAllData=true).
@isTest static void myTestMethod2() {
// Can access all data in the organization.
}
}
This second example shows how to apply the isTest(SeeAllData=true) annotation on a test method. Because the class that the test method is contained in isn’t defined with this annotation, you have to apply this annotation on the test method to enable access to all data for that test method. The second test method doesn’t have this annotation, so it can access only the data it creates in addition to objects that are used to manage your organization, such as users.
// This class contains test methods with different data access levels.
@isTest
private class ClassWithDifferentDataAccess {
// Test method that has access to all data.
@isTest(SeeAllData=true)
static void testWithAllDataAccess() {
// Can query all data in the organization.
}
// Test method that has access to only the data it creates
// and organization setup and metadata objects.
@isTest static void testWithOwnDataAccess() {
// This method can still access the User object.
// This query returns the first user object.
User u = [SELECT UserName,Email FROM User LIMIT 1];
System.debug('UserName: ' + u.UserName);
System.debug('Email: ' + u.Email);
// Can access the test account that is created here.
Account a = new Account(Name='Test Account');
insert a;
// Access the account that was just created.
Account insertedAcct = [SELECT Id,Name FROM Account
WHERE Name='Test Account'];
System.assert(insertedAcct != null);
}
}
IsTest(OnInstall=true) Annotation
Use the IsTest(OnInstall=true) annotation to specify which Apex tests are executed during package installation. This annotation is used for tests in managed or unmanaged packages. Only test methods with this annotation, or methods that are part of a test class that has this annotation, will be executed during package installation. Tests annotated to run during package installation must pass in order for the package installation to succeed. It is no longer possible to bypass a failing test during package installation. A test method or a class that doesn't have this annotation, or that is annotated with isTest(OnInstall=false) or isTest, won't be executed during installation.
This example shows how to annotate a test method that will be executed during package installation. In this example,test1 will be executed but test2 and test3 won't.
public class OnInstallClass {
// Implement logic for the class.
public void method1(){
// Some code
}
}
@isTest
private class OnInstallClassTest {
// This test method will be executed
// during the installation of the package.
@isTest(OnInstall=true)
static void test1() {
// Some test code
}
// Tests excluded from running during the
// the installation of a package.
@isTest
static void test2() {
// Some test code
}
static testmethod void test3() {
// Some test code
}
}
ReadOnly Annotation
The @ReadOnly annotation allows you to perform unrestricted queries against the Force.com database. All other limits still apply. It's important to note that this annotation, while removing the limit of the number of returned rows for a request, blocks you from performing the following operations within the request: DML operations, calls to System.schedule, calls to methods annotated with @future, and sending emails.
The @ReadOnly annotation is available for Web services and the Schedulable interface. To use the @ReadOnly annotation, the top level request must be in the schedule execution or the Web service invocation. For example, if a Visualforce page calls a Web service that contains the @ReadOnly annotation, the request fails because Visualforce is the top level request, not the Web service.
Visualforce pages can call controller methods with the @ReadOnly annotation, and those methods will run with the same relaxed restrictions. To increase other Visualforce-specific limits, such as the size of a collection that can be used by an iteration component like <apex:pageBlockTable>, you can set the readonly attribute on the <apex:page> tag to true. For more information, see Working with Large Sets of Data in the Visualforce Developer's Guide.
Working with Large Sets of Data
Visualforce custom controllers and controller extensions are subject to Apex governor limits. For more information about governor limits, see Execution Governors and Limits. Additionally, Visualforce iteration components, such as<apex:pageBlockTable> and <apex:repeat>, are limited to a maximum of 1,000 items in the collection they iterate over.
Sometimes your Visualforce pages may need to work with or display larger sets of data, but not need to make modifications to that data; for example, if you are providing custom reporting and analytics. Visualforce offers developers a “read-only mode”, which relaxes the limit on the number of rows which can be queried in one request, and increases the limit on the number of collection items which can be iterated over within the page.
You can specify read-only mode either for an entire page or, with certain limitations, on individual components or methods.
Setting Read-Only Mode for an Entire Page
To enable read-only mode for an entire page, set the readOnly attribute on the <apex:page> component to true.
For example, here is a simple page that will be processed in read-only mode:
<apex:page controller="SummaryStatsController" readOnly="true">
<p>Here is a statistic: {!veryLargeSummaryStat}</p>
</apex:page>
The controller for this page is also simple, but illustrates how you can calculate summary statistics for display on a page:
public class SummaryStatsController {
public Integer getVeryLargeSummaryStat() {
Integer closedOpportunityStats =
[SELECT COUNT() FROM Opportunity WHERE Opportunity.IsClosed = true];
return closedOpportunityStats;
}
}
Normally, queries for a single Visualforce page request may not retrieve more than 50,000 rows. In read-only mode, this limit is relaxed to allow querying up to 1,000,000 rows.
In addition to querying many more rows, the readOnly attribute also increases the maximum number of items in a collection that can be iterated over using components such as <apex:dataTable>, <apex:dataList>, and <apex:repeat>. This limit increased from 1,000 items to 10,000. Here is a simple controller and page demonstrating this:
public class MerchandiseController {
public List<Merchandise__c> getAllMerchandise() {
List<Merchandise__c> theMerchandise =
[SELECT Name, Price__c FROM Merchandise__c LIMIT 10000];
return(theMerchandise);
}
}
<apex:page controller="MerchandiseController" readOnly="true">
<p>Here is all the merchandise we have:</p>
<apex:dataTable value="{!AllMerchandise}" var="product">
<apex:column>
<apex:facet name="header">Product</apex:facet>
<apex:outputText value="{!product.Name}" />
</apex:column>
<apex:column>
<apex:facet name="header">Price</apex:facet>
<apex:outputText value="{!product.Price__c}" />
</apex:column>
</apex:dataTable>
</apex:page>
While Visualforce pages that use read-only mode for the entire page can’t use data manipulation language (DML) operations, they can call getter, setter, and action methods which affect form and other user interface elements on the page, make additional read-only queries, and so on.
Setting Read-Only Mode for Controller Methods
Visualforce controller methods can, with some important limitations, use the Apex ReadOnly annotation, even if the page itself isn’t in read-only mode.
Visualforce controller methods with the @ReadOnly annotation automatically take advantage of read-only mode. However, restrictions on the @ReadOnly annotation means that, for Visualforce controller methods, a read-only method must also have the @RemoteAction annotation. The @RemoteAction annotation requires that the method be:
· Either global or public
· static
Enabling read-only mode by using the @ReadOnly annotation must be done on the top level method call. If the top level method call doesn’t have the@ReadOnly annotation, the normal restrictions on maximum queried rows are enforced for the entire request, even if secondary methods are annotated with @ReadOnly.
Using the @ReadOnly annotation on a controller method allows you to retrieve a larger collection of records as the result of a Visualforce expression. However, it doesn’t increase the maximum number of items in a collection for iteration components. If you want to iterate over larger collections of results, you need to enable read-only mode for the entire page.
RemoteAction Annotation
The RemoteAction annotation provides support for Apex methods used in Visualforce to be called via JavaScript. This process is often referred to as JavaScript remoting.
Methods with the RemoteAction annotation must be static and either global or public.
A simple JavaScript remoting invocation takes the following form.
[***namespace***.]controller.method(
[parameters...,]
callbackFunction,
[configuration]
);
Table 1. Remote Request Elements
Element
|
Description
|
namespace
|
The namespace of the controller class. This is required if your organization has a namespace defined, or if the class comes from an installed package.
|
controller
|
The name of your Apex controller.
|
method
|
The name of the Apex method you’re calling.
|
parameters
|
A comma-separated list of parameters that your method takes.
|
callbackFunction
|
The name of the JavaScript function that will handle the response from the controller. You can also declare an anonymous function inline. callbackFunction receives the status of the method call and the result as parameters.
|
configuration
|
Configures the handling of the remote call and response. Use this to change the behavior of a remoting call, such as whether or not to escape the Apex method’s response
|
In your controller, your Apex method declaration is preceded with the @RemoteAction annotation like this:
@RemoteAction
global static String getItemId(String objectName) { ... }
Apex @RemoteAction methods must be static and either global or public.
Your method can take Apex primitives, collections, typed and generic sObjects, and user-defined Apex classes and interfaces as arguments. Generic sObjects must have an ID or sobjectType value to identify actual type. Interface parameters must have an apexType to identify actual type. Your method can return Apex primitives, sObjects, collections, user-defined Apex classes and enums, SaveResult, UpsertResult, DeleteResult, SelectOption, or PageReference.
For more information, see “JavaScript Remoting for Apex Controllers” in the Visualforce Developer's Guide.
TestSetup Annotation
Methods defined with the @testSetup annotation are used for creating common test records that are available for all test methods in the class.
Syntax
Test setup methods are defined in a test class, take no arguments, and return no value. The following is the syntax of a test setup method.
@testSetup static void methodName() {
}
If a test class contains a test setup method, the testing framework executes the test setup method first, before any test method in the class. Records that are created in a test setup method are available to all test methods in the test class and are rolled back at the end of test class execution. If a test method changes those records, such as record field updates or record deletions, those changes are rolled back after each test method finishes execution. The next executing test method gets access to the original unmodified state of those records.
You can have only one test setup method per test class.
Test setup methods are supported only with the default data isolation mode for a test class. If the test class or a test method has access to organization data by using the @isTest(SeeAllData=true) annotation, test setup methods aren’t supported in this class. Because data isolation for tests is available for API versions 24.0 and later, test setup methods are also available for those versions only.
Using Test Setup Methods
Use test setup methods (methods that are annotated with @testSetup) to create test records once and then access them in every test method in the test class. Test setup methods can be time-saving when you need to create reference or prerequisite data for all test methods, or a common set of records that all test methods operate on.
Test setup methods can reduce test execution times especially when you’re working with many records. Test setup methods enable you to create common test data easily and efficiently. By setting up records once for the class, you don’t need to re-create records for each test method. Also, because the rollback of records that are created during test setup happens at the end of the execution of the entire class, the number of records that are rolled back is reduced. As a result, system resources are used more efficiently compared to creating those records and having them rolled back for each test method.
If a test class contains a test setup method, the testing framework executes the test setup method first, before any test method in the class. Records that are created in a test setup method are available to all test methods in the test class and are rolled back at the end of test class execution. If a test method changes those records, such as record field updates or record deletions, those changes are rolled back after each test method finishes execution. The next executing test method gets access to the original unmodified state of those records.
Syntax
Test setup methods are defined in a test class, take no arguments, and return no value. The following is the syntax of a test setup method.
@testSetup static void methodName() {
}
Example
The following example shows how to create test records once and then access them in multiple test methods. Also, the example shows how changes that are made in the first test method are rolled back and are not available to the second test method.
@isTest
private class CommonTestSetup {
@testSetup static void setup() {
// Create common test accounts
List<Account> testAccts = new List<Account>();
for(Integer i=0;i<2;i++) {
testAccts.add(new Account(Name = 'TestAcct'+i));
}
insert testAccts;
}
@isTest static void testMethod1() {
// Get the first test account by using a SOQL query
Account acct = [SELECT Id FROM Account WHERE Name='TestAcct0' LIMIT 1];
// Modify first account
acct.Phone = '555-1212';
// This update is local to this test method only.
update acct;
// Delete second account
Account acct2 = [SELECT Id FROM Account WHERE Name='TestAcct1' LIMIT 1];
// This deletion is local to this test method only.
delete acct2;
// Perform some testing
}
@isTest static void testMethod2() {
// The changes made by testMethod1() are rolled back and
// are not visible to this test method.
// Get the first account by using a SOQL query
Account acct = [SELECT Phone FROM Account WHERE Name='TestAcct0' LIMIT 1];
// Verify that test account created by test setup method is unaltered.
System.assertEquals(null, acct.Phone);
// Get the second account by using a SOQL query
Account acct2 = [SELECT Id FROM Account WHERE Name='TestAcct1' LIMIT 1];
// Verify test account created by test setup method is unaltered.
System.assertNotEquals(null, acct2);
// Perform some testing
}
}
Test Setup Method Considerations
· Test setup methods are supported only with the default data isolation mode for a test class. If the test class or a test method has access to organization data by using the @isTest(SeeAllData=true) annotation, test setup methods aren’t supported in this class. Because data isolation for tests is available for API versions 24.0 and later, test setup methods are also available for those versions only.
· You can have only one test setup method per test class.
· If a fatal error occurs during the execution of a test setup method, such as an exception that’s caused by a DML operation or an assertion failure, the entire test class fails, and no further tests in the class are executed.
· If a test setup method calls a non-test method of another class, no code coverage is calculated for the non-test method.
TestVisible Annotation
Use the TestVisible annotation to allow test methods to access private or protected members of another class outside the test class. These members include methods, member variables, and inner classes. This annotation enables a more permissive access level for running tests only. This annotation doesn’t change the visibility of members if accessed by non-test classes.
With this annotation, you don’t have to change the access modifiers of your methods and member variables to public if you want to access them in a test method. For example, if a private member variable isn’t supposed to be exposed to external classes but it should be accessible by a test method, you can add the TestVisible annotation to the variable definition.
This example shows how to annotate a private class member variable and private method with TestVisible.
public class TestVisibleExample {
// Private member variable
@TestVisible private static Integer recordNumber = 1;
// Private method
@TestVisible private static void updateRecord(String name) {
// Do something
}
}
This is the test class that uses the previous class. It contains the test method that accesses the annotated member variable and method.
@isTest
private class TestVisibleExampleTest {
@isTest static void test1() {
// Access private variable annotated with TestVisible
Integer i = TestVisibleExample.recordNumber;
System.assertEquals(1, i);
// Access private method annotated with TestVisible
TestVisibleExample.updateRecord('RecordName');
// Perform some verification
}
}
Apex REST Annotations
Six new annotations have been added that enable you to expose an Apex class as a RESTful Web service.
RestResource Annotation
The @RestResource annotation is used at the class level and enables you to expose an Apex class as a REST resource.
These are some considerations when using this annotation:
· The URL mapping is relative to https://instance.salesforce.com/services/apexrest/.
· A wildcard character (*) may be used.
· The URL mapping is case-sensitive. A URL mapping for my_url will only match a REST resource containing my_url and not My_Url.
· To use this annotation, your Apex class must be defined as global.
URL Guidelines
URL path mappings are as follows:
· The path must begin with a '/'
· If an '*' appears, it must be preceded by '/' and followed by '/', unless the '*' is the last character, in which case it need not be followed by '/'
The rules for mapping URLs are:
· An exact match always wins.
· If no exact match is found, find all the patterns with wildcards that match, and then select the longest (by string length) of those.
· If no wildcard match is found, an HTTP response status code 404 is returned.
The URL for a namespaced classes contains the namespace. For example, if your class is in namespace abc and the class is mapped to your_url, then the API URL is modified as follows:https://instance.salesforce.com/services/apexrest/abc/your_url/. In the case of a URL collision, the namespaced class is always used.
HttpDelete Annotation
The @HttpDelete annotation is used at the method level and enables you to expose an Apex method as a REST resource. This method is called when an HTTP DELETE request is sent, and deletes the specified resource.
To use this annotation, your Apex method must be defined as global static.
HttpGet Annotation
The @HttpGet annotation is used at the method level and enables you to expose an Apex method as a REST resource. This method is called when an HTTP GET request is sent, and returns the specified resource.
These are some considerations when using this annotation:
· To use this annotation, your Apex method must be defined as global static.
· Methods annotated with @HttpGet are also called if the HTTP request uses the HEAD request method.
HttpPatch Annotation
The @HttpPatch annotation is used at the method level and enables you to expose an Apex method as a REST resource. This method is called when an HTTP PATCH request is sent, and updates the specified resource.
To use this annotation, your Apex method must be defined as global static.
HttpPost Annotation
The @HttpPost annotation is used at the method level and enables you to expose an Apex method as a REST resource. This method is called when an HTTP POST request is sent, and creates a new resource.
To use this annotation, your Apex method must be defined as global static.
HttpPut Annotation
The @HttpPut annotation is used at the method level and enables you to expose an Apex method as a REST resource. This method is called when an HTTP PUT request is sent, and creates or updates the specified resource.
To use this annotation, your Apex method must be defined as global static.
