Dreamforce 2014 Notes: Write Apex Tests Using Best Practices

Sharing is Caring

One of the hands on training sessions I attended was “Write Apex Tests Using Best Practices” which really proved to me that a lot of what I believed and was doing were right.

Without further ado, here’s my notes:

Goals for tests

Auomated methods that verify application integrity
Future Proof
Proactively Identify Problems before they enter production
Salesforce Runs all customer tests before updates
Postive tests & Negative tests

Classes that are demarcated by the @isTest annontation won’t count against Apex code limit
contain member methods that can only be contained & used in a test

tests always have a void return type & no params
tests are always static
single autonomous transaction
only heap space, governor, etc
tests should insert their own test data
tests should be able to handle uncaught exceptions, etc
tests should have assertions to determine validity

Tests Leave No Footprint

Apex tests will not commit changes. SOQL still finds records
will not performs callouts to external web services
will not send outbound email

Tests Expect to Work with Mock Data

static resources can be used to stage test data in a cache
SOSL searches will not find pre-existing records
SOQL queries will only find pre-existing records for the following objects:
- User
- Profile
- Organization
- RecordType
- For all other objects, SOQL visibility may be overridden with @isTest(seeAllData=true)

Governors

verify code is bulk ready
pass up to 200 records

Verify End State

using assertions

Best Practices

Don’t Depend on Pre-Existing Data

Avoid SOQL to initalize SOQL using SeeAllData=true
- less portable
- inconsistent results
Utilize mock data
Call Test.loadData() in a test method to populate
Create reusable mock data factories
Triggers should never contain business logic, they should only contain calls to classes
Use a Naming Convention like NameOfClass_Test
Exclude mock data initialization and result verification actions from governor calculations
Create separate tests with narrow goals

Challenges

blue boxes: test logic
grey boxes: business logic

Testing Visualforce Controllers

Mimic VisualForce page interactions by explicity calling methods
- Form fields, eg form.Name use getter/setters
Test controller extensions by mocking the controller that was extended

Test.startTest synchronously runs asynchronous Apex

Testing Callouts

developers need to implement mock calls and responses that do not access the web services
setMock() needs to be run to do the fake response and call out

Testing Record Access