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.

Customize error message for trigger and display error message below the field

This Post demonstrates how to display error message in particular field level.

SObject SomeRecord;

SomeRecord.SomeField__c.addError('Custom Message');

//or

SomeRecord.someField__c.addError(someException);

Note:

We cannot add it to a field dynamically. This error mapping can only be done with a hard-coded field.

Useful Links:
https://salesforce.stackexchange.com/questions/79291/how-to-use-adderror-with-a-dynamically-derived-field-name

List has no rows for assignment to SObject  error

 Consider following query:

   
      id p;

      user u = [SELECT Id from user where Name = :username];

      if (u != null)

      p = u.Id;

•  The above code will fail if there is no user record with the matching username. It doesn't actually return a null.

 It would be safer to do the following:

    id p;

     user[] userlist = [SELECT Id from user where Name = :username];

     if (userlist.size() > 0)

       p = userlist[0].Id;