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

Brian is a software architect and technology leader living in Niagara Falls with 13+ years of development experience. He is passionate about automation, business process re-engineering, and building a better tomorrow.

Brian is a proud father of four: two boys, and two girls and has been happily married to Crystal for more than ten years. From time to time, Brian may post about his faith, his family, and definitely about technology.