function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

What are the best practices for Salesforce Testing?

I'd like to set up a more formal testing process for our salesforce instance. We have good code coverage on our Apex tests but I really want to test our functionality end-to-end (such as typical scenarios for certain types of users, that will include testing workflow rules and validation rules) . I could do this via Apex tests but I've got a couple of concerns.

1) Maintainability - as rules are added and removed, this might be hard to maintain.
2) Test run time - this will add a LOT more tests to Salesforce so deployments may take some time. 

I've also looked into Selenium but I don't really need to do UI testing - it's more functional testing and Apex tests will ensure test data is deleted. 

Are there best practices for setting this up? Can anyone point me to documentation on this? 
Amit Chaudhary 8Amit Chaudhary 8
Please check below post. I hope that will help you

You Can use below App Exchange product to see code coverage of all classes

Please check below post for testing Best Pratice

Unit Test Mechanism in Salesforce

1) Single action
Test to verify that a single record produces the correct, expected result. So created the unit test data in your test class.

2) Bulk actions
Any Apex code, whether a trigger, a class or an extension, may be invoked for 1 to 200 records. You must test not only the single record case, but the bulk cases as well.

3) Restricted user
Test whether a user with restricted access to the sObjects used in your code sees the expected behavior. That is, whether they can run the code or receive error messages. Always use RunAs for to check user access on sObjects.

4) Positive behaviour
Test to verify that the expected behaviour occurs through every expected permutation, that is, that the user filled out everything correctly and did not go past the limits.

5) Negative behaviour
There are likely limits to your applications, such as not being able to add a future date, not being able to specify a negative amount, and so on. You must test for the negative case and verify that the error messages are correctly produced as well as for the positive, within the limits cases.

Please follow below salesforce Best Practice for Test Classes :-

1. Test class must start with @isTest annotation if class class version is more than 25
2. Test environment support @testVisible , @testSetUp as well
3. Unit test is to test particular piece of code working properly or not .
4. Unit test method takes no argument ,commit no data to database ,send no email ,flagged with testMethod keyword .
5. To deploy to production at-least 75% code coverage is required
6. System.debug statement are not counted as a part of apex code limit.
7. Test method and test classes are not counted as a part of code limit
9. We should not focus on the  percentage of code coverage ,we should make sure that every use case should covered including positive, negative,bulk and single record .
Single Action -To verify that the the single record produces the correct an expected result .
Bulk action -Any apex record trigger ,class or extension must be invoked for 1-200 records .
Positive behavior : Test every expected behavior occurs through every expected permutation , i,e user filled out every correctly data and not go past the limit .
Negative Testcase :-Not to add future date , Not to specify negative amount.
Restricted User :-Test whether a user with restricted access used in your code .10. Test class should be annotated with @isTest .
11 . @isTest annotation with test method  is equivalent to testMethod keyword .
12. Test method should static and no void return type .
13. Test class and method default access is private ,no matter to add access specifier .
14. classes with @isTest annotation can't be a interface or enum .
15. Test method code can't be invoked by non test request .
16. Stating with salesforce API 28.0 test method can not reside inside non test classes .
17. @Testvisible annotation to make visible private methods inside test classes.
18. Test method can not be used to test web-service call out . Please use call out mock .
19. You can't  send email from test method.
20.User, profile, organization, AsyncApexjob, Corntrigger, RecordType, ApexClass, ApexComponent ,ApexPage we can access without (seeAllData=true) .
21. SeeAllData=true will not work for API 23 version eailer .
22. Accessing static resource test records in test class e,g List<Account> accList=Test.loadData(Account,SobjectType,'ResourceName').
23. Create TestFactory class with @isTest annotation to exclude from organization code size limit .
24. @testSetup to create test records once in a method  and use in every test method in the test class .
25. We can run unit test by using Salesforce Standard UI, IDE ,Console ,API.
26. Maximum number of test classes run per 24 hour of period is  not grater of 500 or 10 multiplication of test classes of your organization.
27. As apex runs in system mode so the permission and record sharing are not taken into account . So we need to use system.runAs to enforce record sharing .
28. System.runAs will not enforce user permission or field level permission .
29. Every test to runAs count against the total number of DML issued in the process .

Please let us know if this post will help you

Amit Chaudhary
Thanks for the detailed response, Amit. Good to know #28 - I'll need to look into that a bit more. I'm doing okay on the test class side of things for testing our custom code. What I'm really looking for is an overall QA strategy for our entire system (including functionality that is covered by point-and-click dev and not custom code). I've been having a hard time finding any documentation on best practices for this, although I have found a couple of automated testing tools (which, with my budget of $0, won't really work for me). I think I may go ahead with writing these all as test classes and essentially create my own automated testing tool. Ugh, this is going to take a long time!
Adam SandmanAdam Sandman
For those interested in other ways to do the end to end testing, we had a webinar a few weeks ago on testing, there is a video recording of the webinar available (