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
- use System.runAs() methods to verify test users can find records that were shared with apex
- using System.runAs() is a best practice.