Custom Metadata Types vs Custom Settings vs Custom Labels 💬 In plain words: Three lookalikes: Custom Metadata = configuration that DEPLOYS with your code (best for app settings). Custom Settings = org/user-specific values, changeable at runtime (hierarchy type is great for bypass switches). Custom Labels = translatable text for the UI. 📌 Example: API endpoint URLs per environment → Custom Metadata (deploys with code, sandbox vs prod values). A 'Bypass_Automation__c' checkbox an admin flips during data load → hierarchy Custom Setting. The word 'Submit' translated to Hindi → Custom Label. 🎬 Real-Life Example: The Fee Table Trapped Inside Code Skyline charges a different delivery fee per city. Apex needs those rates on every booking. The Old/Bad Way: if (city == 'Delhi') fee = 50. Else if (city == 'Mumbai') fee = 65. … Every rate change is a code change, a test run, and a deployment. Why this is bad: Business data is trappe...
Here's an example of a well-structured Apex test class for a Salesforce application:
@isTest
public class MyApexTestClass {
// Test method to validate a specific functionality
@isTest
static void testFunctionality() {
// Test data setup
// Create necessary test records
// Perform any additional setup required for the test
// Test the functionality
Test.startTest();
// Call the method being tested or perform the necessary actions
// Assert the expected results using System.assertEquals or System.assert methods
Test.stopTest();
// Perform assertions and validate the results
// Use System.assertEquals or System.assert methods to check the expected results against actual results
// Clean up any test data or perform necessary cleanup operations
}
// Test method to validate another functionality
@isTest
static void testAnotherFunctionality() {
// Test data setup
// Create necessary test records
// Perform any additional setup required for the test
// Test the functionality
Test.startTest();
// Call the method being tested or perform the necessary actions
// Assert the expected results using System.assertEquals or System.assert methods
Test.stopTest();
// Perform assertions and validate the results
// Use System.assertEquals or System.assert methods to check the expected results against actual results
// Clean up any test data or perform necessary cleanup operations
}
// Additional test methods for other functionalities can be added here
}
In the above example, the '@isTest' annotation is used to define the class as a test class. The test methods 'testFunctionality()' and 'testAnotherFunctionality()' represent different functionalities being tested.
Inside each test method, you can set up the necessary test data, perform the actions being tested, and assert the expected results using 'System.assertEquals()' or 'System.assert' methods.
The 'Test.startTest()' and 'Test.stopTest()' methods are used to mark the beginning and end of the code that should be covered by Salesforce's governor limits, such as the number of SOQL queries or DML statements.
After the 'Test.stopTest()' call, you can perform assertions to validate the results, and clean up any test data created during the test if required.
You can add additional test methods for testing other functionalities in your Salesforce application as needed. Remember to cover different scenarios and edge cases to ensure comprehensive testing.