Unit testing in Apex has several benefits: 1. It forces developers to define requirements, which testing then validates. 2. Unit tests provide free regression testing and target compatibility testing. 3. Well-written unit tests can achieve code coverage requirements with less effort.

1. Apex Unit Testing in the Real World
Dan Appleman, Full Circle CRM, CTO
Author: “Advanced Apex Programming for Salesforce.com and Force.com”
@danappleman

2. Safe Harbor
Safe harbor statement under the Private Securities Litigation Reform Act of 1995:
This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if
any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-
looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of
product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of
management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments
and customer contracts or use of our services.
The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our
service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth,
interruptions or delays in our Web hosting, breach of our security measures, the outcome of intellectual property and other litigation, risks associated
with possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain,
and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling
non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the
financial results of salesforce.com, inc. is included in our annual report on Form 10-Q for the most recent fiscal quarter ended July 31, 2012. This
documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site.
Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may
not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently
available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.

3. Recommended Testing Best Practices
Single action
Test to verify that a single record produces the correct, expected result.
Bulk actions
Any Apex code, whether a trigger, a class or an extension, may be invoked for 1 to 200 records. You must test not only
the single record case, but the bulk cases as well.
Positive behavior
Test to verify that the expected behavior occurs through every expected permutation, that is, that the user filled out
everything correctly and did not go past the limits.
Negative behavior
There are likely limits to your applications, such as not being able to add a future date, not being able to specify a
negative amount, and so on. You must test for the negative case and verify that the error messages are correctly
produced as well as for the positive, within the limits cases.
Restricted user
Test whether a user with restricted access to the sObjects used in your code sees the expected behavior. That is,
whether they can run the code or receive error messages.

4. Why don’t we do it?
Consultants?
In-house Developers?
Package Developers?

5. Let’s Play a Game

6. 20,000 Fictional Apex Developers were asked – why write
unit tests?

7. 20,000 Fictional Apex Developers were asked – why write
unit tests?

8. 20,000 Fictional Apex Developers were asked – why write
unit tests?

9. 20,000 Fictional Apex Developers were asked – why write
unit tests?

10. 20,000 Fictional Apex Developers were asked – why write
unit tests?

11. 20,000 Fictional Apex Developers were asked – why write
unit tests?

12. 20,000 Fictional Apex Developers were asked – why write
unit tests?

13. Testing to Requirements
1. Forces you to actually define requirements
2. Validates that what you built meets requirements
3. “Free” regression testing
4. “Free” target compatibility
5. May even get you code coverage.

14. All Testing is Bulk Testing - I
Bad code
public static testmethod void test1bad()
{
Lead ld = new Lead(LastName='Testname',
Company='Testcompany');
Test.StartTest();
insert ld;
Test.StopTest();
Lead leadres = [Select ID from Lead where
ID = :ld.id];
// Do some assert here
}

15. All Testing is Bulk Testing - II
Better code
public static testmethod void test1better()
{
List<Lead> lds = new List<Lead>{
new Lead(LastName='Testname',
Company='Testcompany')};
Test.StartTest();
insert lds;
Test.StopTest();
Map<ID, Lead> leadsmap = new Map<ID, Lead>(lds);
List<Lead> leadres = [Select ID from Lead where
ID in :leadsmap.keyset()];
// Do some asserts here
}

16. All Testing is Bulk Testing - III
Centralize object initialization
public static List<Lead> InitTestLeads(
Integer count)
{
List<Lead> lds = new List<Lead>();
for(Integer x = 0; x< count; x++)
{
lds.add(new Lead(LastName='Testname' +
String.ValueOf(x), Company='Testcompany' +
String.ValueOf(x)));
}
return lds;
}

17. All Testing is Bulk Testing - IV
Pull test code into a separate method
public static void test2support(Integer batchsize)
{
List<Lead> lds = InitTestLeads(batchsize);
Test.StartTest();
insert lds;
Test.StopTest();
Map<ID, Lead> leadsmap = new Map<ID, Lead>(lds);
List<Lead> leadres = [Select ID from Lead where
ID in :leadsmap.keyset()];
// Do some asserts here
}

18. All Testing is Bulk Testing – Oh yeah!
And let the magic happen
@istest(oninstall=true)
public static void test2single()
{
Test2Support(1);
}
@istest(oninstall=false)
public static void test2bulk()
{
Test2Support(200);
}

19. Results:
Direct functional/requirements validation
Free regression testing
Free target compatibility
Cheap bulk testing
Lower maintenance costs
Most code coverage met

20. Bonus for Package Developers
You can block tests using oninstall=false, but still need 75%
code coverage to install.
How do you shut down individual tests?
How do you initialize object fields to address validation rules on
a target system?
How do you customize behavior during install while maintaining
a single code base?

21. Static Resources to the Rescue
Field initialization info
Centralized object Static Resource
Initialization function
Control test
execution
Allow test to run?
Test function
Control behavior
Other code
(test or functional)
resources = [Select Body from StaticResource where Name = ‘predeployedresource' ];

22. Conclusion
You can’t (and shouldn’t) ignore the economics of testing.
Making general testing goals a priority over code coverage is the
sound economic choice.

23. Next Steps
Question for chatter – tell us about a testing
challenge you overcame.
Stop by and chat at the Full Circle CRM booth
btw… we’re hiring
www.AdvancedApex.com

24. No question? – Tell us about your favorite testing technique.

25. AdvancedApex.com