Apex Testing

The following are the benefits of Apex unit tests:

• Ensuring that your Apex classes and triggers work as expected.
• Having a suite of regression tests that can be rerun every time classes and triggers are updated to ensure that no future updates you make to your app break existing functionality.
• Meeting the code coverage requirements for deploying Apex to production or distributing Apex to customers via packages.
• High quality apps delivered to the production org, which makes production users more productive.
• High quality apps delivered to package subscribers, which increase your customers trust.

Before each major service upgrade, Salesforce runs all tests in all organizations with Apex code to make sure that no behavior in custom code has been altered as a result of any service upgrades. A side benefit of having Apex unit tests in your org is that Salesforce will run your tests for you and check that they work in each new release.

Before you can deploy your code or package it for the Force.com​ AppExchange, at least 75% of Apex code must be covered by tests and all those tests must pass. In addition, each trigger must have some coverage. Even though code coverage is a requirement for deployment, you shouldn’t write tests only to meet this requirement. Make sure to test the common use cases in your app, including positive and negative test cases, and bulk and single-record processing.

Test methods take no arguments and have the following syntax:

1	@isTest static void testName() {

2	// code_block

3

}

Alternatively, a test method can have this syntax:

1	static testMethod void testName() {

2	// code_block

3

}

** Using the isTest annotation instead of the testMethod keyword is more flexible as you can specify parameters in the annotation.

The visibility of a test method doesn’t matter, so declaring a test method as public or private doesn’t make a difference as the testing framework is always able to access test methods. For this reason, the access modifiers are omitted in the syntax.

Test methods must be defined in test classes, which are classes annotated with isTest. This is a definition of a test class with one test method.

1

@isTest

2	private class MyTestClass {

3	@isTest static void myTest() {

4	// code_block

              System.assertEquals(-23.33,-23.33);

              System.assertEquals(100,-23.33,'Boiling point temperature is not expected.');

5

}

6

}

Test classes can be either private or public. If you’re using a test class for unit testing only, declare it as private. Public test classes are typically used for test data factory classes

The verifications are done by calling the System.assertEquals()method, which takes two parameters: the first is the expected value, and the second is the actual value. There is another version of this method that takes a third parameter—a string that describes the comparison being done. This optional string is logged if the assertion fails.

Salesforce records that are created in test methods aren’t committed to the database; they’re rolled back when the test finishes execution. This rollback behavior is handy for testing because you don’t have to clean up your test data after the test executes.

By default, Apex tests don’t have access to pre-existing data in the org, except for setup and metadata objects that can be accessed such as the User or Profile objects. You should set up test data for your tests. Creating test data makes your tests more robust and prevents failures that are caused by missing or changed data in the org. You can create test data directly in your test method, or by using a utility test class as you’ll find out later.

Even though it is not a best practice to do so, there might be times when a test method needs access to pre-existing data. To access org data, annotate the test method with @isTest(SeeAllData=true). The test method examples in this unit don’t access org data and therefore don’t use the SeeAllData parameter.

• Up to 3 MB of Apex code can be saved in each org. Test classes annotated with isTest don’t count toward this limit.
• Even though test data rolls back, no separate database is used for testing. As a result, for some sObjects that have fields with unique constraints, inserting duplicate sObject records results in an error.
• Test methods don’t send emails.
• Test methods can’t make callouts to external services. You can use mock callouts in tests.
• SOSL searches performed in a test return empty results. To ensure predictable results, you can use Test.setFixedSearchResults() to define the records to be returned by the search.

The test method contains the Test.startTest() and Test.stopTest() method pair, which delimits a block of code that gets a fresh set of governor limits. In this test, test-data setup uses two DML statements before the test is performed. To test thatApex code runs within governor limits, isolate data setup’s limit usage from your test’s. To isolate the data setup process’s limit usage, enclose the test call within the Test.startTest() and Test.stopTest() block. Also use this test block when testing asynchronous Apex.