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

  • use System.runAs() methods to verify test users can find records that were shared with apex
  • using System.runAs() is a best practice.
Sharing is Caring