0

I am writing a test class for a TriggerHandler called 'HasPotentialDuplicates'. I am checking to see if a duplicate record exists using a custom checkbox field I made called 'HasPotentialDuplicates'. The field updates to 'true' if there is a duplicate record.

I have a second method where I insert 2 accounts, with different names, then update them to the same name. This triggers the duplicate rule and should mark the 'HasPotentialDuplicates' checkbox as true.

My question is; When writing the SOQL, how can I differentiate between the records? They have the same names so I am unable to distinguish between them.

public static testMethod void test2() {
    Account acc3 = new Account();
    acc3.Name = 'Test3';
    Account acc4 = new Account();
    acc4.Name = 'Test4';

    INSERT acc3;
    INSERT acc4;
    
    acc4.name = 'Test3';
        
    UPDATE acc4;

    Test.startTest();
    Account HasPotentialDuplicate3 = [SELECT ID, Has_Potential_Duplicates__c FROM Account WHERE Name = 'Test3'];
    Account HasPotentialDuplicate4 = [SELECT ID, Has_Potential_Duplicates__c FROM Account WHERE Name = 'Test3'];
    Test.stopTest();

    System.assertEquals(HasPotentialDuplicate3.Has_Potential_Duplicates__c, true);
    System.assertEquals(HasPotentialDuplicate4.Has_Potential_Duplicates__c, true);
}

2 Answers 2

3

Just filter by Id.

Account queried3 = [SELECT Has_Potential_Duplicates__c FROM Account WHERE Id = :acct3.Id];

Some important notes:

  • Proper syntax is:
    • system.assertEquals(expectedValue, actualValue, message)
    • While message is optional, including it will make your tests much more useful and durable as a valuable source of documentation to help understand your code base.
  • A good naming convention would strongly discourage any abbreviations, as they harm readability and make anyone who reads the code later guess to fill in the gaps.
  • Another readability tip is to put only the code you are specifically testing inside Test.startTest()/Test.stopTest(). While it does more properly frame your governor behavior, I find in most cases the only difference is cosmetic.
  • You should prefer @IsTest to testmethod, as the latter is deprecated.
  • SObject construction is slightly faster if you populate fields using field-value pairs in its constructor.
  • Less important, but you actually don't even need a separate Account variable, so you can make your test a little more compact by reusing what you already have.

Cleaned up example:

@IsTest static void myTestMethod()
{
    Account record1 = new Account(SomeField = someValue);
    Account record2 = new Account(SomeField = someValue);
    
    // other data setup
    
    Test.startTest();
        update record2;
        // this call is what you are actually testing
    Test.stopTest();
    
    record1 = [SELECT MyCheckbox__c FROM Account WHERE Id = :record1.Id];
    system.assertEquals(true, record1.MyCheckbox__c, 'Duplicates based on <SomeField> should be flagged');
    
    record2 = [SELECT MyCheckbox__c FROM Account WHERE Id = :record2.Id];
    system.assert(record2.MyCheckbox__c, 'Duplicates based on <SomeField> should be flagged');
    // this syntax works as well
}
0

Update your queries to filter by Id as well

Account HasPotentialDuplicate3 = [SELECT ID, Has_Potential_Duplicates__c FROM Account WHERE Name = 'Test3' and id = :acc3.id];
Account HasPotentialDuplicate4 = [SELECT ID, Has_Potential_Duplicates__c FROM Account WHERE Name = 'Test3' and Id =:acc4.id];

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .