Salesforce Apex Ten Commandments


Published on

Learn the top 10 things you must know when developing using Salesforce APEX!

Published in: Internet
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Declarative crazy. 500+ fields on an object, loads of workflows – It can get really hard to see what’s going on in the same way bad coding can be hard.

  • Unit tests, by definition test a unit of code. They are not Method tests, testing an entire method, or Functional tests, testing the behaviour of an entire class
    If the method you’re testing does multiple units of work, you’d ideally split it up into individual methods each doing one thing, but failing that, at least write one unit test per unit of work.
    In other words, if you had a method that created Accounts AND contacts, be sure to write positive, negative and user tests for the the account creation bit of that method, and the contact creation unit of that method.
    Not one unit test that did both.
  • Salesforce Apex Ten Commandments

    1. 1. Apex Ten Commandments Francis Pindar @radnip Cloud Sherpas
    2. 2. #1 Thou shalt not put queries in ‘for’ loops
    3. 3. #1 Thou shalt not put queries in ‘for’ loops
    4. 4. #2 Thou shalt not put DML in ‘for’ loops
    5. 5. #2 Thou shalt not put DML in ‘for’ loops
    6. 6. #3 Thou shalt have a happy balance between clicks & code  Code that replicates declarative functionality – Roll-up Summary – Workflows – Email Templates – Global Settings – … Good Salesforce Architectural Design
    7. 7. #4 Thou shalt only put one trigger per object
    8. 8. #5 Thou shalt not put code in triggers other than calling methods and managing execution order
    9. 9. #6 Thou shalt utilize maps for queries wherever possible
    10. 10. #7 Thou shalt make use of relationships to reduce queries wherever possible
    11. 11. #8 Thou shalt aim for 100% test coverage  In general test your methods for: – Positive effects. • Given proper input it should act like this. • Not just happy path, but all logic branches. – Negative effects. • Given bad data it should error like this. – Role/Profile/User effects • Given a user with X profile and Y role it should act like this.
    12. 12. #9 Thou shalt write meaningful and useful tests  It’s not a test without assertions. – Assert(A==B, “Assert failed comment”) – AssertEquals(A,B, “Assert failed comment”) – AssertNotEquals(A,B, “Assert failed comment”)
    13. 13. #9 Thou shalt write meaningful and useful tests  Test with your own data – Use Test.StartTest() / Test.StopTest()
    14. 14. #9 Thou shalt write meaningful and useful tests  Test one thing at a time – Maintain Focus – Just One Thing!
    15. 15. #10 Thou shalt limit future calls and use asynchronous code where possible  In general bias towards batch apex – Ensure it runs as efficiently as possible. • Limit and tune time outs for callouts. • Tune soql queries for efficiency – dev console can help here. – If you need @future methods. • Optimize them the same way you would optimize your batch apex. • Resist methods that would queue many @future calls at once. (governor limits!)
    16. 16. Thanks… Questions? How to find me: Ask an Expert – 3pm to 6pm Twitter: @radnip