Adding Test Methods - Apex Unit Tests

Now that you’ve added a utility class that is called by the test method to create some data used for testing, you’re ready to create the class that contains the test methods. Follow this procedure to add a test class and test methods.

1. In the Repository tab, click Classes in the Setup Entity Type section, and then click New.
2. For the class name, enter TestInvoiceStatementDeletion and click OK.
3. Delete the auto-generated code and add the following.
   @isTest
   private class TestInvoiceStatementDeletion {
   
       static testmethod void TestDeleteInvoiceWithLineItem() {
           // Create an invoice statement with a line item then try to delete it 
       
           Invoice_Statement__c inv = TestDataFactory.createOneInvoiceStatement(true);
           Test.startTest();
           Database.DeleteResult result = Database.delete(inv, false);
           Test.stopTest();
   
           // Verify invoice with a line item didn't get deleted.  
       
           System.assert(!result.isSuccess());
       }
   
       static testmethod void TestDeleteInvoiceWithoutLineItems() {
           // Create an invoice statement without a line item and try to delete it 
       
           Invoice_Statement__c inv = TestDataFactory.createOneInvoiceStatement(false);
           Test.startTest();
           Database.DeleteResult result = Database.delete(inv, false);
           Test.stopTest();
   
           // Verify invoice without line items got deleted.  
       
           System.assert(result.isSuccess());
       }
   
       static testmethod void TestBulkDeleteInvoices() {
           // Create two invoice statements, one with and one with out line items 
       
           // Then try to delete them both in a bulk operation, as might happen 
       
           // when a trigger fires. 
       
           List<Invoice_Statement__c> invList = new List<Invoice_Statement__c>();
           invList.add(TestDataFactory.createOneInvoiceStatement(true));
           invList.add(TestDataFactory.createOneInvoiceStatement(false));
           Test.startTest();
           Database.DeleteResult[] results = Database.delete(invList, false);
           Test.stopTest();
   
           // Verify the invoice with the line item didn't get deleted 
       
           System.assert(!results[0].isSuccess());
   
           // Verity the invoice without line items did get deleted. 
       
           System.assert(results[1].isSuccess());
       }
   }
   

4. Click Save.

Tell Me More...

• The class is defined with the @isTest annotation. You saw this annotation in the previous lesson to define a common test utility class. In this lesson, this annotation is used to mark the class as a test class to contain test methods that Apex can execute. Note that any Apex class can contain test methods mixed with other code when not defined with this annotation, but it is recommended to use it.
• The class contains three test methods. Test methods are static, top-level methods that take no arguments. They’re defined with the testmethod keyword or the@isTest annotation. Both of these forms are valid declarations:
  Declaration of a test method using the testmethod keyword:

  static testmethod void myTest() {
      // Add test logic 
      
  }

  Declaration of a test method using the @isTest annotation:

  static @isTest void myTest() {
      // Add test logic 
      
  }

• Here is a description of each test method in this class:
  • TestDeleteInvoiceWithLineItem: This test method verifies that the trigger does what it is supposed to do—namely it prevents an invoice statement with line items from being deleted. It creates an invoice statement with a line item using the test factory method and deletes the invoice using theDatabase.deleteApex method. This method returns a Database.DeleteResult object that you can use to determine if the operation was successful and get the list of errors. The test calls the isSuccess method to verify that it is false since the invoice shouldn’t have been deleted.
  • TestDeleteInvoiceWithoutLineItems: This test method verifies that the trigger doesn’t prevent the deletion of invoice statements that don’t have line items. It inserts an invoice statement without any line items and then deletes the invoice statement. Like the previous method, it calls the test factory method to create the test data and then calls Database.delete for the delete operation. The test verifies that the isSuccess method of Database.DeleteResultreturns true.
  • TestDeleteInvoiceWithoutLineItems: Last but not least, this third test method performs a bulk delete on a list of invoices. It creates a list with two invoice statements, the first of which has one line item and the second doesn’t have any. It calls Database.delete by passing a list of invoice statements to delete. Notice that this time we have a second parameter. It is an optional Boolean parameter that indicates whether the delete operation on all sObjects should be rolled back if the deletion on some sObjects fails. We passed the value false, which means the delete DML operation shouldn’t be rolled back on partial success and the sObjects that don’t cause errors will be deleted. In this case, the test calls the isSuccess method of Database.DeleteResult to verify that the first invoice statement isn’t deleted but the second one is.
• Each test method executes the delete DML operation within Test.startTest/Test.stopTest blocks. Each test method can have only one such block. All code running within this block is assigned a new set of governor limits separate from the other code in the test. This ensures that other setup code in your test doesn’t share the same limits and enables you to test the governor limits. Although this isn’t critical in our case since we’re deleting one or two records at a time and won’t be hitting any limits; however, it’s good practice to enclose the actual test statements within Test.startTest/Test.stopTest. You can perform prerequisite setup and test data creation prior to calling Test.startTest and include verifications after Test.stopTest. The original set of governor limits are reverted to after the call toTest.stopTest.