I used a static resource to perform a unit test on the loading of a sample contact. Previously, code coverage was at 0% and improved to 1% after running the test. My code is as follows:

 public static testMethod void testLoadData(){
    List<Contact> contacts = (List<Contact>)
        System.Test.loadData(Contact.sObjectType, 'testcontactData');
    system.assert(contacts.Size() == 2);
    system.assert(contacts[0].FirstName == 'John');
    system.assert(contacts[1].LastName == 'Doe');


Since I'm just testing the contact object, and my base class involves bot opportunities and accounts as well as contacts, should I create separate testMethods in the same test class? How much will my test coverage improve by employing this technique of testing load data into accounts and opportunities over and above the 1% where we stand now?

Thanks much for your help and guidance.

Update: After creating tests for account, contact and opportunity, code coverage for specific triggers increased into the acceptable range. This is a good thing, but the target class deals largely with parsing XML from a REST response and adding the contents of child nodes into various fields. I created mocks in my test class to callout the RESTful response to no avail. At this point, I need to achieve coverage on the larger class that entails parsing XML nodes into various fields. Can anyone suggest further guidance? Do we need to consider re-writing the class into smaller classes?

Your continued assistance is appreciated.

  • 2
    There are various ways to setup data for tests. Often it is simpler to do explicit inserts in the tests including setting up parent/child relationships. The important point is that the data matches the code you are trying to test. If your code is in triggers then insert/update/delete of objects will cause the code to run, but if your code is in other classes such as controllers you will have to directly call the code from your test methods.
    – Keith C
    Aug 25, 2014 at 16:25

2 Answers 2


Here's a link to a document that describes how to write good unit tests in apex if you haven't read it. https://developer.salesforce.com/page/How_to_Write_Good_Unit_Tests

Writing good tests is about making tests for your code. For instance, if your code is processing an update to a record, you would need to insert the record first and then update the record to make sure the update logic is hit and you get the expected result. You may need to insert multiple records of different types to do so. If you were testing and Order update trigger and Orders required an Account and a Contact. You would need to insert the Account and Contact before you could insert the Order. So in this scenario the unit test would 1. insert the record(s)(Account, Contact and Order) to prepare for the test 2. make an update to the Order record. 3. retrieve the updated Order record for validation 4. validate that the changes were made.


A useful pattern (if testing triggers) following @Keith C's suggestion would be

private static void testContactTriggers() {
  List<Account> aList = new List<Account> {
                           new Account(name = '00Acct'), 
                           new Account(name = '01Acct'),
                           new Account(name = '09Acct')
  insert aList;

  List<Contact> cList = new List<Contact> {
                           new Contact(accountid = aList[0].id,
                                       lastname = '00_0Lname', email = '[email protected]'),
                           new Contact(accountid = aList[0].id,
                                       lastname = '00_1Lname', email = '[email protected]'),

                           new Contact(accountid = aList[1].id,
                                       lastname = '01_0Lname', email = '[email protected]'),
  insert cList;

  List<Contact> cResList = [select id, accountId, otherfield1__c, otherfield2__c 
                              from Contact where ID IN: cList order by lastname;

  System.assertEquals(someExpectedValue, cResList[0].otherField1__c);
  System.assertEquals(someExpectedValue, cResList[1].otherField1__c);
  System.assertEquals(someExpectedValue, cResList[2].otherField1__c);


Of course there are many other ways to do this and a lot depends on the nature of what your code is doing and what you want to assert being true. The pattern allows for multiple scenarios to be tested in one operation and is readily extensible to new test cases (just add new combinations of Contacts and Accounts). The pattern will avoid (usually) the 'too many SOQL calls' in one testmethod as operations are done in bulk.

Test.startTest() and Test.stopTest() should also be used to wrap the actual operations you want to test and hence the setup code/DML doesn't affect governor limits.

As @Mark Wochnick said, read the doc on testing for more details.

(I omitted Opportunities for clarity)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .