What are the best practices followed when writing a test class?

Hey,

You can refer to  https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_best_practices.htm

Thanks

• This reply was modified 8 years, 6 months ago by  shafali.

1. All test methods should reside in a separate class from the class in which the method being tested resides.
2. Test classes should be appended with the word Test followed by the name of the class being tested, e.g. OpportunityServicesTest should be test class name if the controller class name is OpportunityServices.
3. Should all use the @isTest annotation.
4. Each method in the production class should have, at a minimum, one corresponding test method in its test class and should be appended by “test”
5. There should be a minimum of “Null Pointer Exception test” as part of negative testing for each method, specially the methods that accept parameters.
6. A method without an assert statement is not considered a test method. Large number of relevant assert statements increases confidence in the correct behavior of business logic.
7. There should be a comment with each assert statement explaining what is being tested and what the expected output is.
8. Only use isTest(SeeAllData = true) on class methods in exceptional cases where there are sObjects that doesn't allow DML operation e.g. PriceBook creation.
9. No hard coded ids of any sObject in any test method.
10. If a Constant needs to be asserted, its a best practice to reference that from the Constant class or from Custom Labels or Custom Settings. Using hard coded string in unit tests( or any class for that matter) will trigger failures when things like Picklist values change.
11. All test data creation should be done from a Utility class. This allows for a streamlined creation of test objects that adhere to all the validation rules.
12. Any business logic that needs to be tested should be enveloped within a Test.runAs(user) statement so profile restrictions can be tested. Using any admin profiles should be avoided.
13. All private methods should also have its corresponding unit test method. In the production code, add a public method for each private method and prepend it by “exposeForUnitTest_”.
14. Creating multiple test method for testing that same production code method should be avoided. We want to ensure that our unit test methods are properly testing the logic but the same time the efficiency of the unit test method should not be ignored. All the unit test methods run with every deployment so the cumulative run time should be as small as possible
15. Any asynchronous method testing should include Test.startTest and Test.stopTest. Test.stopTest forces the asynchronous methods to run so the results could be asserted.
16. Any exceptions that are caught in the production methods should be tested by feeding the test data that throws exception. Exception Type and error message should be asserted.