In previous blog post, we discussed best practices of writing Test classes in Apex. In old school way, if we wanted to create records for test methods, helper or utility classes were favorite option for developers.
However this approach has few disadvantages
Multiple Test classes could depend on these utility methods
It creates tight coupling between classes
Deployment could be slow if unnecessary test record being created for test methods
If class to create test record is not marked with @isTest then it will count against allowed apex code in instance
Test classes needs to explicitly call method to create test records
There are many resources and documents available around how to use Test.loadData to create test records in Apex class. As per best practice of writing Test classes in Apex, Its good idea to store master data (aka Seed, Reference data) in static resource and load it in Test classes using “Test.loadData” method. It will save lots of code around creating test records and at the same time easy to maintain. We can store records of Custom settings, standard or custom object which can be used frequently in our code. One of the best functionality to make writing Test classes more easier, As we don’t need to concentrate on writing code for creating data, time can be used to assert actual functionality.
So the question is, How can we load related records using Test.loaddata() method ? Simply by creating fake Salesforce Ids, that’s right !!! It is possible.
Here I am going to share few answers related to Test Classes, which is being asked many times to me by novice Programmers. Please feel free to post Comments if your question is not answered here. I will try my best to add those Questions in this article. If you want to learn Test Class from very basic, you can check this article also.
What are some Best Practices while writing Test Classes ?
Well, It differs from person to person, as every programmer has its own style of writing code. However I will list few of mine.
Very important and first, “Test Coverage Target Should not be limited to 75%”. It is not about coverage, It is about testing complete functionality. It will be always better if your code fails during test execution, It will be less devastating than failing functionality after product release.
If possible Don’t use seeAllData=true, Create your Own Test Data.
Always use @testSetup method dedicated to create test records for that class. This is newly added annotation and very powerful. Any record created in this method will be available to all test methods of that class. Using @testSetup method will improve test execution performance by creating test records only once for that class. If you are not using this, means test record is created in each TestMethod which will be very slow. Read this Salesforce documentation for more information.
Create Different Class which will create Dummy Data for testing, and use it everywhere (You have to be very careful, as sometimes it may slow down test class execution by creating unnecessary data which does not require by every test methods. So few developer prefer test data creation per Test class)
If your Object’s Schema is not changing frequently, you can create CSV file of records and load in static resource. This file will act as Test data for your Test Classes.
Use As much as Assertions like System.AssertEquals or System.AssertNotEquals
Use Test.startTest() to reset Governor limits in Test methods
If you are doing any Asynchronous operation in code, then don’t forget to call Test.stopTest() to make sure that operation is completed.
Use System.runAs() method to enforce OWD and Profile related testings. This is very important from Security point of View.
Always try to pass null values in every methods. This is the area where most of program fails, unknowingly.
Always test Batch Capabilities of your code by passing 20 to 100 records.
Use Test.isRunningTest() in your code to identify that context of class is Test or not. You can use this condition with OR (||) to allow test classes to enter inside code bock. It is very handy while testing for webservices, we can generate fake response easily.
@TestVisible annotation can be used to access private members and methods inside Test Class. Now we don’t need to compromise with access specifiers for sake of code coverage.
End your test class with “_Test”. So that in Apex Class list view, Main class and Test class will come together, resulting easy navigation and time saver.