Soql Queries and Sub Queries

In the below query there are total 3 subqueries + 1 parent query. So, there are 4 queries. But, Salesforce doesn't count subqueries against governor limit of 100 SOQLs. It counts only root query which means only 1 SOQL query would be consumed.

List<Account> dd = [
    SELECT
        id,
        (SELECT Name FROM Contacts),  // <- first subquery
        (SELECT AccountID FROM Cases) // <- second subquery
    FROM
        Account
    WHERE
        id
    IN (SELECT AccountID FROM Case)   // <- not counted
];


Subqueries are counted separately as AggregateQueries. You can check those with Limits.getAggregateQueries() and Limits.getLimitAggregateQueries(). You cannot have more than 300 aggregations in a single transaction.

For example: Org contain  only 2 Account and each have 10 Contacts.

 If you execute this with sub Query like below

Select Id, Name, (Select Id, Name from Contacts) From Account

Then the total number of Query rows will be 22 (2+10+10).

 From above analogy we can understand like this:

 If your org contain 40M accounts and each have 1 contact.

Then in this scenario you can use sub query up to 25M only.

 Like this Select Id, Name, (Select Id, Name from Contacts) From Account limit 25M

will System.debug, if left in production, affect performance ?

Code executed, including System.Debug and System.assert (and their variants) have the following effects:

1) They increase debug log sizes.
2) They increase script execution time (but insignificantly).
3) They count against governor limits.

The final bullet point is your most troubling concern. A loop against 1000 records with 10 debug statements will have a total of 10,000 extra script statements than the one without.

The salesforce.com best practices state that you should always remove or comment debug statements for production code

Test.setup:

• @testSetup ( Set Up Test Data for an Entire Test Class )Use test setup methods (methods that are annotated with @testSetup) to create test records once and then access them in every test method in the test class.
• Test setup methods can reduce test execution times especially when you’re working with many records
• Test setup methods enable you to create common test data easily and efficiently.
• Test setup methods enable you to create common test data easily and efficiently.

@isTest
private class CommonTestSetup
{
 @testSetup
 static void setup()
 {
  Account acct = new Account();
       acct.Name = 'Salesforce.com';
       acct.Industry = 'Technology';
  insert acct;

  Contact cont = new Contact();
       cont.FirstName = 'Annappa';
       cont.LastName = 'ph';
       cont.AccountId = acct.Id;
  insert cont;
 }
 
 @isTest
 static void testMethod1()
 {
  Account acct = [SELECT Id FROM Account WHERE Name='Salesforce.com' LIMIT 1];
     acct.Phone = '555-1212';
  update acct;
 }

 @isTest
 static void testMethod2()
 {
  Account acct = [SELECT Phone FROM Account WHERE Name='Salesforce.com' LIMIT 1];
  System.assertEquals(null, acct.Phone);
 }
}

Note:

If a test class contains a test setup method, the test setup method executes first, before any test method in the class.
Multiple @testSetup methods are allowed in a test class, but the order in which they’re executed by the testing framework isn’t guaranteed
If the test class or a test method has access to organization data by using the @isTest(SeeAllData=true) annotation, test setup methods aren’t supported in this class.

 Date Formats and Date Literals
                                                 

DateTime field values are stored as Coordinated Universal Time (UTC).

When a dateTime value is returned in Salesforce, it’s adjusted for the time zone specified in your org preferences.

If you want to process these values in different time zones, your application might need to handle the conversion.

For a fieldExpression that uses date formats, the date is not enclosed in single quotes. Don’t use quotes around the date.

For example:

SELECT Id
FROM Account
WHERE CreatedDate > 2016-10-08T01:02:03Z

Date Literals:

Simple Queries:


 SELECT Id FROM Account WHERE CreatedDate = YESTERDAY

SELECT Id FROM Account WHERE CreatedDate > TODAY

SELECT Id FROM Opportunity WHERE CloseDate = TOMORROW

SELECT Id FROM Account WHERE CreatedDate > LAST_WEEK

SELECT Id FROM Account WHERE CreatedDate < THIS_WEEK

SELECT Id FROM Account WHERE CreatedDate < THIS_MONTH

SELECT Id FROM Account WHERE CreatedDate = LAST_90_DAYS

Salesforce Basics :

Using same List for Update:

List<Account> acList=[select id,name from account limit 2];
system.debug('>>>acList>>>>'+acList);
for(account ac:acList){
    ac.name='Test';
}
system.debug('before update List>>'+acList);
update acList;

Here "acList" contains Updated value



Will It Updates.Parents name field?

List<Contact> contactList=[select id,accountId,account.name from contact limit 2];
for(contact c:contactList){
c.account.name='Update Parent Account';
}

update contactList;

Ans: It will not

Apex Code Coverage Hack

Declaimer: please be aware that all things into this article are “bad practice” and should not be used constantly, it might be used for a really urgent production deployment when you have faced with a broken tests and as a result a code coverage has dropped down than 75% and you has been blocked.

As you know salesforce requires at least 75% test coverage for production deployment. You can find the following statement in documentation:

The code coverage percentage for a class or trigger displayed on the Apex Classes or the Apex Triggers page includes a fraction between parentheses with the numbers used to compute this percentage, for example, 90% (72/80). The code coverage percentage is calculated by dividing the number of lines covered by tests by the total number of lines that are part of the coverage calculation. Some lines of code are excluded from code coverage calculation, such as:

• Comments
• System.debug statements
• Test methods

A code statement that is broken up into multiple lines—only the first line is counted
To generate code coverage results, you must run your Apex tests first. If no tests have been run, no code coverage data will exist and 0% (No coverage data) displays for classes (except for test classes) and triggers on the Apex Classes and Apex Triggers pages.

Cool! The code coverage calculation is pretty simple and we can cheat the system. Just use the following code


/*
Please improve your tests and remove this class as soon as possible
*/
public class CodeCoverageHack {
    public static void hack() {
        Integer i = 0;
        i++;
        i++;
        i++;
        i++;
        i++;
        i++;
        // you can continue this method with i++; up to 3000 lines
        // after that you would be stoped by limit of size
        // but you can create a few such methods
 }

    public static void hack1() {
         // do the same thing ...
    }

    @isTest static void runTest() {
        CodeCoverageHack.hack();
        CodeCoverageHack.hack1();
        //...
        CodeCoverageHack.hackN();
    }
}
That’s all.   ✌

How to run future method in test class

We have to use future method inside the  startTest/stopTest:

Test.startTest();
myClass.futuremethod( someID );
Test.stopTest();

Test.stopTest() does not return until your future method has completed.