20

Testing and Debugging

Some of the most important activities as a Salesforce professional will be testing and debugging. Setting up your testing plan will depend on the types of environments you set up for the path to production. These environments will be a combination of one or more sandboxes and your final production Salesforce instance. Once the path to production is defined, there are several stages of testing.

In this chapter, we will cover the following topics in detail:

• Understanding the path to production
• Setting up the path to production
• Understanding testing types
• Using debug logs

With the help of these topics, you will be able to set up your Salesforce sandbox strategy and create a testing plan for your deployments.

Technical requirements

For this chapter, make sure you log in to your development org and follow along as we work through the different testing and debugging features available to a system administrator.

Understanding the path to production

The path to production is the strategy for how new features and bug fixes are delivered to your live production Salesforce org. There are different scenarios that require different strategies, including:

• New Salesforce implementations
• Smaller enhancement projects
• Bug fixes

In this chapter, we will cover the new Salesforce implementation scenario.

Business use case

You are the Salesforce admin for XYZ Widgets. XYZ Widgets has been using a legacy system and has decided to move to Salesforce. You are tasked with setting up the environment strategy.

Setting up the path to production

As a best practice, you will set up the following strategy for your implementation. This strategy includes different types of sandboxes and how to use each one in the process of getting code and functionality to production:

Figure 20.1: The path to production

1. The developer sandboxes are used for building separate functionality for your implementation. The number of these sandboxes depends on how many development teams are working on the project. Each team should have its own sandbox to work in.
2. The SIT or System Integration Testing sandbox is where all the code from the developer sandboxes is merged and tested. This is typically a dev pro sandbox that has more storage than developer sandboxes. Each developer would push their code to the SIT sandbox and test to make sure there are no conflicts with other code.
3. The UAT or User Acceptance Testing sandbox is where the users will test the functionality. This is preferably a full sandbox so that users can test with data.
4. In this scenario, we are looking at a new Salesforce implementation, so we will need a migration sandbox. This is typically a full sandbox where the data is loaded for validation prior to loading data into production.
5. The training sandbox, typically a partial copy sandbox so that users can see data, is used for user training before go-live.
6. The production fixes sandbox is used after go-live. This is for “hot fixes” that need to be made immediately. These are typically bugs that need to be resolved. A developer pro sandbox is recommended.
7. Here you see that all sandboxes refresh from production. You will need to define the interval of refreshes based on sandbox type and implementation requirements.

This example is for a new Salesforce implementation. Different scenarios will require a different mix of the stages shown in the diagram in Figure 20.1. For example, if you are doing a smaller project in an existing Salesforce org, you will need one developer sandbox and one testing sandbox, and then you can push to production. For bug fixes, you would need only the one bug fix sandbox.

Understanding testing types

Now that we have a defined path to production, let’s look at the different types of testing. There are generally five types of testing that will be conducted:

• Unit testing
• System testing
• UAT testing
• Production testing
• Regression testing

Unit testing

Unit tests verify whether a particular piece of code is working properly. This type of testing is done by developers as they build code. Salesforce requires 75% code coverage. Code coverage indicates how many executable lines of code in your classes and triggers have been exercised by test methods. This is important in that code can be developed in sandboxes and tested by users without unit tests. To push that code to production, the unit tests must be written and covered.

Not all implementations include code, and this type of testing is needed only when there is code being written.

System testing

This testing takes place in the SIT sandbox. This is where your team manually tests the functionality that was added from the developer sandboxes. This testing is technical and requires manual test scripts to test the functionality end to end. In addition to testing the new functionality, all existing functionalities should be tested as well to make sure the new feature did not affect existing features in the SIT sandbox.

UAT testing

UAT is where the users test the functionality that has been developed. This is the final gate before pushing to production. This is typically a functional manual test where each functionality is tested and marked as a pass or fail. If it fails, it is sent back to the team to remediate; if it passes, it is ready to push to production. This testing requires test scripts that are written for the users to follow in order to completely test the developed functionality.

Production testing

Once the functionality is pushed to production, another set of manual tests is done. This testing follows the same scripts as UAT testing. During this testing, each functionality is tested to make sure it still works after being pushed from the UAT environment.

Regression testing

Once all code has been pushed to production, the final round of testing is called regression testing. Regression testing is done to ensure the newly deployed code did not affect any existing functionality. This includes testing ALL processes that previously existed in the system. Note that regression testing should also be done during system testing. It is then done again as a final test when all code is in production.

Using debug logs

As an admin, when a user reports an issue, you try to recreate it and resolve it. At times, you are unable to figure out why the issue has occurred, so you need to take a look under the hood. Salesforce offers a feature to view debug logs. The debug log contains information about each transaction, such as whether it was successful and how long it took. Depending on the filters set by your trace flags, the log can contain varying levels of detail about the transaction.

Business use case

Sam, the sales rep, has reported an issue when creating an account. When you, as the administrator, try to recreate the issue, you are unsuccessful. You will set up a debug log to get a deeper understanding of what is happening.

Creating a debug log

Let’s create a debug log for Sam. We will start on the Setup page as shown in Figure 20.2:

Figure 20.2: Navigating to debug logs

On this page, we will take the following steps:

1. Click on Setup.
2. Click on Home.
3. Click on Debug Logs.

This will bring us to the Debug Logs page, as shown in Figure 20.3:

Figure 20.3: Create new debug log

On this page, we will click on New, which brings us to the creation page for debug logs, as shown in Figure 20.4:

Figure 20.4: Create debug log creation page

On this page, we will take the following steps:

1. Enter the Entity Type; in our case, it will be User.
2. Choose the user.
3. Enter the Start and Expiration dates.
4. Enter the Debug Level: To specify the level of information that gets included in debug logs, set up trace flags and debug levels. The debug levels assigned to your trace flags control the type and amount of information that is logged for different events. After logging has occurred, inspect debug events in your debug logs.
5. Click Save.

This brings us back to the Debug Logs page shown in Figure 20.5:

Figure 20.5: Debug log created

Sam is now included under the User Trace Flags. This means any action he takes in the system will be captured as long as it is before the expiration date. You ask Sam to create an account. When he does, you check the debug logs in Figure 20.6:

Figure 20.6: Debug logs created

There are several logs for the actions Sam has performed; click on View to see the details of the log, as shown in Figure 20.7:

Figure 20.7: Debug log detail

Now you have more details to analyze and get to the bottom of the issue! Note that at times, the debug log may show Success, but show an issue in the details, such as governor limit errors for managed packages. To identify issues, you have to read through all line items.

Let’s summarize what we have learned in this chapter.

Summary

In this chapter, we understood what the path to production is and how to set it up for different scenarios. We explored the different types of testing and how they relate to the path to production and various sandbox types. Finally, we discovered how debug logs can help us further investigate issues reported by users.

With this final chapter, we have completed this book and tried to cover as many use cases and examples as possible. I hope that this encourages you to continue your journey with Salesforce, and experiment with more use cases using your development organization and Trailhead.

Questions

1. What does SIT stand for?
2. What does UAT stand for?
3. What type of sandbox works well for data migration?
4. What type of testing is done in the SIT sandbox?
5. What type of testing is done by developers?
6. How does a debug log help troubleshoot?

Further reading

• Debug logs: https://help.salesforce.com/s/articleView?id=sf.code_viewing_log_details.htm&type=5
• Get started with testing: https://trailhead.salesforce.com/content/learn/modules/test-lightning-web-components/get-started-with-testing

Join our community on Discord

Join our community’s Discord space for discussions with the authors and other readers: https://packt.link/rlptF