Testing in Salesforce is not easy. Since many of the classes are standard Salesforce classes that you don’t have any control over, and can’t customize, it’s not easy to find what went wrong and where. Whenever something breaks it always starts with a worrying hunt to check if you have not clashed with some inbuilt CSS or have inherited a class wrongly. The word debugging itself is dreaded by novices and expert architects alike. But even with that said, testing in Salesforce is not that difficult and if you incorporate some best-practices based strategy and some cool tools, you may save lots of efforts in testing, and more specifically repetitive testing.
Testing Best Practices
The forcedotcom platforms development language, APEX, is a higher level language. What that means is that it has an inbuilt feature that helps you write, run, and monitor test cases. Sometimes even the best of forgetting that. With that said, testing in Salesforce is not much different from testing in general. So I won’t be going into obvious (but still widely unfollowed) tricks like using a structured code, using comments to define the use of the function, and covering 100% code using unit tests.
Code Portability
This is the foremost requirement and most experts agree with this one. Your code should not be too dependent on the presence of external data. You would be writing code that uses external data for validations or relies on data like username, data, etc, but too much dependency will break the functionality as soon as you move from development to production environment. Every code should be smart enough to cover the possibility of null or not-present data. You should aim for using relative URLs and SOQL queries for data records. Also when testing in sandbox, test for use-cases where there is no data present. If it passes in such scenarios, it will pass in any environment.
Code coverage
The standard Salesforce directive is that unit test cases should cover 75% of the code, and that’s excluding test methods and test classes. Only then would Salesforce allow you to deploy apex code or package AppExchange apps. But these are just standards. You should aim for 100% coverage.
In my experience, however, the coverage should be use case centric. You should aim to cover all use case in your tests. Test for all positive and negative use cases, and for data presentation and not present. It is a hallmark of expertise to analyze and speculate all possible bad things that can happen, and prepare for things that you have not anticipated.
Writing Test Case In Controllers and Classes
The standard practice in Salesforce development is to create separate controller and classes files for each function. This makes coding easier, more organized, portable, and most importantly reusable. However, I have seen that the same concept is being applied to test classes as well. Its easier to create separate test classes and controllers but ultimately it’s not efficient. Its easier to achieve portability if you include test code in the original controller and class code itself. That way you won’t miss out on any test class when you migrate from sandbox to production.
Assert Based Testing
There is a special class in Apex for checking conditions, named System.assert(). This is an awesome functionality that allows checking for conditions, i.e. it checks whether a function has been performed by the method as expected or not. To know more about the class check out salesforce forum topic, and Salesforce System Class page.
Using assert() classes, specially System.assertEquals() and System.assertNotEquals() between critical functionalities help you to not make sure that the code has been executed perfectly, but also make sure that no data gets written erroneously if the code goes wrong some way.
Testing For Bulk data
An apex trigger can be used to either start data operation through SFDC API or through a user-triggered action like clicking a button. Since the Apex Code is executed in bulk, it becomes it becomes imperative that you test your use cases for handling large data sets, especially for those use cases that involves APIs. It’s important to make sure that code does not offshoot governor limits, or else you will mess up your data very badly. That’s from years of experience in automated Salesforce data migration services.
Tools for Testing
Salesforce testing is in general being carried out in browser or eclipse based environment. Both eclipse and latest browsers have great debugging tools that when combined with test classes can help you greatly. But for those who need something more, Salesforce.com launched a Apex debugging tool named The Apex Interactive Debugger and a chrome extension Salesforce Lightning Inspector for specifically testing Salesforce Lightning.
Automation testing in Salesforce is also possible and Salesforce now even have in-built capabilities to connect with Jasper Control Center API, which is the first step in scheduling and running test jobs.
References:
salesforce, redkitetechnologies, gokubi
Pratyush Kumar
