Testing From The Trenches - Salesforce1 World Tour 2014
•Download as PPTX, PDF•
1 like•392 views
As the Salesforce1 World Tour moves to London on May 22nd 2014, Force.com MVP's Chris Lewis and Simon Lawrence present the 15:00 Developer Stage Session on Testing Best Practices for the Salesforce.com Platform.
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (7)
Similar to Testing From The Trenches - Salesforce1 World Tour 2014
Similar to Testing From The Trenches - Salesforce1 World Tour 2014 (20)
Recently uploaded
Recently uploaded (20)
Testing From The Trenches - Salesforce1 World Tour 2014
- 1. Testing From The Trenches May 22nd, 2014
- 2. Christopher Alun Lewis Advanced Developer Force.com MVP A Developers Perspective Simon Lawrence Certified Developer Force.com MVP http://www.slideshare.net/SimonLawrence4
- 3. Why Do We Test? • Testing is required by Salesforce.com to release code to production environments • Regression Protection Against Future Changes • Salesforce make 3 Platform Releases a Year • Residing in a Multi-Tenancy Environment • To Rid Your Systems of Bugs
- 4. Testing on Salesforce Our 5 Top Tips for Testing
- 5. #1 Always Include Assertions • These are what we call “Skeleton Tests” • Other than avoiding exceptions, provide almost no use • Missing a great opportunity to provide feedback on future failure scenarios
- 6. #1 Always Include Assertions The Code
- 7. #1 Always Include Assertions The Criminal Test
- 8. #1 Always Include Assertions The Correct Test
- 9. #2 Remember your Batch Scenarios • Your code may need to process large collections objects, ensure that your tests cover this • A serious consideration for testing your system’s ability to operate within the governor limits
- 10. #2 Remember your Batch Scenarios The Code
- 11. #2 Remember your Batch Scenarios The Criminal Test
- 12. #2 Remember your Batch Scenarios The Correct Test
- 13. #3 Test Roles with RunAs • Test execution defaults to running as System Admin • Using RunAs allows you to test your sharing rules and record access rights
- 14. #3 Test Roles with RunAs
- 15. #3 Test Roles with RunAs The Correct Test
- 16. #4 Test Every Branch of Logic • Making sure test cases traverse every possible logical route through your code • Crucial pieces of logic can be hidden in IF/ELSE blocks
- 17. #4 Test Every Branch of Logic The Code
- 18. #4 Test Every Branch of Logic The Criminal Test
- 19. #4 Test Every Branch of Logic The Coverage
- 20. #4 Test Every Branch of Logic The Correct Test
- 21. #5 The 75% Squad • Those developers who just strive to get to the 75% mark • Normally guilty of most of the other crimes • There’s no future for their code and their work
- 22. #5 The 75% Squad The Code
- 23. #5 The 75% Squad The Criminal Test
- 24. #5 The 75% Squad The Coverage
- 25. The Wrap Up • Always have test Assertions • Batch test your Triggers • RunAs different Users in your tests • Cover every branch of your logical flow • Don’t just aim for 75%
- 26. Resources • These Slides http://www.slideshare.net/SimonLawrence4 • Developer Resources https://developer.salesforce.com https://developer.salesforce.com/page/How_to_Write_Good_Unit_Tests • Salesforce Stack Exchange http://salesforce.stackexchange.com/
- 27. Thank You! Christopher Alun Lewis @ChrisAlunLewis Simon Lawrence @srlawr
Editor's Notes
- Prefrerredtowritimgimmovativenewcode---no!!
- Prefrerredtowritimgimmovativenewcode---no!!
- A really simple calculator class with one method that by its definition one would assume provides the sum of two numbers Takes two parameters, it’s called “Sum” However, bit of a developer problem, it always returns 42
- Here is our test method to see if our Sum function works We pass two pairs of numbers i This test passes, and we have 100% code coverage
- Here is our test method to see if our Sum function works We pass two pairs of numbers i This test passes, and we have 100% code coverage
- No control over how many records Salesforce might send to a trigger Helps detect limit exceptions, but also race conditions and deadlocks Inefficient code can cause transactions to roll back repeatedly blocking functionality The primary example is triggers, but we also need to mention there can be controller code that has to deal with this
- Here is our example, a really simple trigger that when a contact is inserted if it’s parent account doesn’t have a phone number, the contact number is copied into that record and saved Now this code is probably going to get you into trouble in a production environment… No concept of batchification … who can spot what governor limit you are at risk of breaking here (SOQL first – 100, and then DML -150)
- Here is our test (explain code: create data, startTest stopTest, reload accounts, assert value copy) This test will run our trigger and it will pass, and even give you 100% coverage That is no good though, because in live, our trigger will very likely fail due to limit exceptions
- We have introduced a loop which will test our trigger in a scenario of 200 contacts being added This will now throw the limit exception and force us to correct our code before deployment
- Complicated custom controllers We spend a lot of time on role hierarchies and record sharing, so why do we so often neglect to test it
- Here’s a pretty standard, and very simple Sales Team set up Now imagine you had a strict requirement that the members of the Sales Team could NOT see each others opportunities – for competitive purposes This is easy enough to implement and manually test, but how can you be sure such sharing rules are consistently implemented, and never accidently invalidated or overridden? You’d want a test case for it – important thing to remember to test, but so rarely addressed
- Load profile Load role Create two users
- Another small snippet of code, a simple function that manages a division scenario This time a significant mathematical flaw at line 10 in which we divide by zero
- This accompanying test class has two methods to test this class, sending a positive and a negative value to our method. It passes just fine, and even achieves 85% test coverage, so we might think we are all good to go But lets see what the result of running this test is on the class
- The handy code coverage indicator tells us exactly what lines are not covered, and it’s line 10.. Whilst we might think we are good to release here, we need to examine the uncovered lines, consider what test conditions will cover it, and test it accordingly Otherwise we are going to end up having problems down the line
- The handy code coverage indicator tells us exactly what lines are not covered, and it’s line 10.. Whilst we might think we are good to release here, we need to examine the uncovered lines, consider what test conditions will cover it, and test it accordingly Otherwise we are going to end up having problems down the line
- Our final criminal act is something we call the 75% Squad Not focussed on testing, just on getting to 75%
- Here are four simple mathematical methods Provide 9 lines of testable code Therefore we need to cover 7 of them to be hit the “release point” of 75%
- Here is our simple test case thrown together (No asserts) It Tests a few methods and it passes no problem Lets look at the results
- So the coverage is 77% (above 75%) - we can release Using the handy code coverage indicator in the Developer Console again See some code that is not tested, but will be released with the rest of it The 75% mark is not Salesforce just saying you can skip the last 25% of your tests. It’s to allow realistic coverage targets. You’re not aiming for 75%, your aiming for complete test scenario coverage – and that will *get* you past 75%. There is NO reason not to test this method – unless you are blinded by that 75%