Using Developer Console to Troubleshoot Code

Confessional time: my org is a mess. There have been way too many developers in it and over time it has become a giant pile of triggers and code. It can be a bit intimidating to clean up, but the developer console can help. In this post I’ll show how I use some of the features of the dev console to find where my code can be improved.

One of my tests recently stopped working due to the dreaded “Too many SOQL queries” error. I was able to find the offending SOQL statements with the help of the developer console.

First, open up the console so logging will be captured. In Salesforce, perform that action to replicate the problem or execute the code you want to look at. You should see the log appear in the Logs list. Open the log and switch perspective to Analysis (Debug > Switch Perspective > Analysis(Predefined). This perspective gives you tons of information.

I’m interested in the Executed Units tab under Execution Overview. Since I know I have a problem with my queries, I click on all the buttons except for Queries to make only Queries visible. This gives us a list of all the queries executed. Immediately, I can see a few queries that were executed 16 times! Uh oh. Looks like I have some code that can be optimized. With my new knowledge, I can work towards making my code bulk friendly.

analysis perspective


Take some time to poke around in the perspectives. It really gives you insight into how your code is executing. Happy spelunking!

Yet Another Test Factory

When writing unit tests, it is best practice to centralize the creation of all your test data. While there are a lot of examples of ways to do that on the web (SmartFactory ), I’ve never been completely satisfied with them. SmartFactory is great if you want to be sure you have data in all your fields, but since I know my org and what the data should look like, I prefer to specify field values. Some of the problems I wanted to solve:

  • Minimize number of code statements executed (SmartFactory makes debug logs huge).
  • Have different object templates for various scenarios.
  • Be able to override values for specific one-offs tests.

You can find the code on Github in my Salesforce-Smart-Factory repository. Here’s how you can use it.

// To create an object, just pass an instance of the new object to the method.
// The TestFactory will pre-fill all the fields we typically need
Account a = (Account)TestFactory.createSObject(new Account());
insert a;
// You can also set values to be used. Any values set in the constructor will override the defaults
Opportunity o = (Opportunity)TestFactory.createSObject(new Opportunity(AccountId = a.Id));
// You can also specify a specific set of overrides for different scenarios
Account a = (Account)TestFactory.createSObject(new Account(), 'TestFactory.AccountDefaults');
// Finally, get a bunch of records for testing bulk
Account[] aList = (Account[])TestFactory.createSObjectList(new Account(), 200);