Testing

Question 1

Describe Apex Unit Tests

Answer 1

• Unit tests are class methods that verify whether a particular piece of code is working properly.
• Unit test methods take no arguments, commit no data to the database, send no emails, and are flagged with the testMethod keyword or the isTest annotation in the method definition.
• Also, test methods must be defined in test classes, that is, classes annotated with isTest.
• Classes and methods defined as isTest can be either private or public. The access level of test classes methods doesn’t matter. This means you don’t need to add an access modifier when defining a test class or test methods. The default access level in Apex is private. The testing framework can always find the test methods and execute them, regardless of their access level.
• Classes defined as isTest must be top-level classes and can’t be interfaces or enums.

Methods of a 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.

Here are some things to note about unit tests.

• Starting with Salesforce API 28.0, test methods can no longer reside in non-test classes and must be part of classes annotated with isTest. See the TestVisible annotation to learn how you can access private class members from a test class.
• Test methods can’t be used to test Web service callouts. Instead, use mock callouts. See Test Web Service Callouts and Testing HTTP Callouts.
• You can’t send email messages from a test method.
• Since test methods don’t commit data created in the test, you don’t have to delete test data upon completion.
• If a test class contains a static member variable, and the variable’s value is changed in a testSetup or test method, the new value isn’t preserved. Other test methods in this class get the original value of the static member variable. This behavior also applies when the static member variable is defined in another class and accessed in test methods.
• For some sObjects that have fields with unique constraints, inserting duplicate sObject records results in an error. For example, inserting CollaborationGroup sObjects with the same names results in an error because CollaborationGroup records must have unique names.
• Tracked changes for a record (FeedTrackedChange records) in Chatter feeds aren’t available when test methods modify the associated record. FeedTrackedChange records require the change to the parent record they’re associated with to be committed to the database before they’re created. Since test methods don’t commit data, they don’t result in the creation of FeedTrackedChange records. Similarly, field history tracking records (such as AccountHistory) can’t be created in test methods because they require other sObject records to be committed first (for example, Account).
• If code uses conditional logic (including ternary operators), execute each branch.
• Make calls to methods using both valid and invalid inputs.
• Complete successfully without throwing any exceptions, unless those errors are expected and caught in a try…catchblock.
• Always handle all exceptions that are caught, instead of merely catching the exceptions.
• Use System.assert methods to prove that code behaves properly.
• Use the runAs method to test your application in different user contexts.
• Exercise bulk trigger functionality—use at least 20 records in your tests.
• Use the ORDER BY keywords to ensure that the records are returned in the expected order.
• Test the classes in your application individually. Never test your entire application in a single test.

Question 2

Describe the testing framework and requirements for deployment.

Answer 2

There are two ways of testing an application. One is through the Salesforce user interface, important, but merely testing through the user interface will not catch all of the use cases for your application. The other way is to test for bulk functionality: up to 200 records can be passed through your code if it’s invoked using SOAP API or by a Visualforce standard set controller.

An application is seldom finished. You will have additional releases of it, where you change and extend functionality. If you have written comprehensive tests, you can ensure that a regression is not introduced with any new functionality.

Before you can deploy your code or package it for the Force.com​ AppExchange, the following must be true.

• At least 75% of your Apex code must be covered by unit tests, and all of those tests must complete successfully.
• Note the following.
  
  • When deploying Apex to a production organization, each unit test in your organization namespace is executed by default.
  • Calls to System.debug are not counted as part of Apex code coverage.
  • Test methods and test classes are not counted as part of Apex code coverage.
  • While only 75% of your Apex code must be covered by tests, your focus shouldn’t be on the percentage of code that is covered. Instead, you should make sure that every use case of your application is covered, including positive and negative cases, as well as bulk and single records. This should lead to 75% or more of your code being covered by unit tests.
• Every trigger must have some test coverage.
• All classes and triggers must compile successfully.
• Private Class Members:
  
  • ​Test methods are defined in a test class, separate from the class they test. This can present a problem when having to access a private class member variable from the test method, or when calling a private method. Because these are private, they aren’t visible to the test class. You can either modify the code in your class to expose public methods that will make use of these private class members, or you can simply annotate these private class members with TestVisible. When you annotate private or protected members with this annotation, they can be accessed by test methods and only code running in test context.

Question 3

Describe how to write unit tests for triggers, controllers, and classes.(Be clear on Test.startTest() and Test.stopTest() about how governor limit gets reset)

Answer 3

Triggers

• test Triggers by inserting, updating or deleting test data (use a utility class if you do this alot)
• then using Test.startTest() and Test.stopTest() isolate the production code.
• example:
  
  • test around a record insert to see an insert trigger perform what is needed.

Controllers

• test controllers by exercising controller methods including get and set.
• use Page.Success and Page.Failure

Classes

• test positive cases & Bulk
• test negative cases and all edge cases
• test as multiple user types (System.runAs)

Question 4

Describe when and how to use various sources of test data.

Answer 4

Manually

You should create test data within your test class whenever possible but:

• if you can’t, use the SeeAllData=True annotation to @isTest to make org data visible to test class.
• 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.
• these objects are always available to test classes:
  
  • User, Profile, Organization, AsyncApexJob, CronTrigger, RecordType, ApexClass, ApexTrigger, ApexComponent, ApexPage
• Tracked changes in chatter feeds arent available as they need database commits to occur. Simlarly, Field history tracking doesnt exist either.

Load Test Data

• Store data in a .csv in a static resource
  
  • text/csv, application/vnd.ms-excel, application/octet-stream, text/plain
• Call Test.loadData within a test method to quickly load test data into the text execution context.

Use Common Test Utility Classes for data creation

Use 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 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.
• Multiple test setup methods are allowed in a test class, but the order in which they’re executed by the testing framework isn’t guaranteed.
• 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.

Question 5

Describe how to execute one or multiple test classes.

Answer 5

Yo​u 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:

• The Salesforce user interface
• The Force.com IDE
• The Force.com Developer Console
• The API

Question 6

Anonymous blocks can?

Answer 6

• Can include user-defined methods and exceptions.
• User-defined methods cannot include the keyword static.
• You do not have to manually commit any database changes.
• If your Apex trigger completes successfully, any database changes are automatically committed. If your Apex trigger does not complete successfully, any changes made to the database are rolled back.
• Unlike classes and triggers, anonymous blocks execute as the current user and can fail to compile if the code violates the user’s object- and field-level permissions.
• Do not have a scope other than local. For example, though it is legal to use the global access modifier, it has no meaning. The scope of the method is limited to the anonymous block.
• When you define a class or interface (a custom type) in an anonymous block, the class or interface is considered virtual by default when the anonymous block executes. This is true even if your custom type wasn’t defined with thevirtual modifier. Save your class or interface in Salesforce to avoid this from happening. Note that classes and interfaces defined in an anonymous block aren’t saved in your organization.

Describe the differences between invoking Apex in execute anonymous vs. unit test

• Unit test executes in system mode and any changes made to records are not visible out of its test execution context where with anonymous block any changes performed to data are visible after its execution is successful.
• Code written in anonymous block is not stored as metadata in salesforce org and user permissions are enforced during execution.