[SalesForce] System.AssertException: Assertion Failed: Same value

This is related to Lightning Specialist Superbadge step 6 – Automate fulfillment cancellation actions.

The task is when fulfillment is Cancelled, the related OpportunityLineItem unitprice (i.e., salesprice) should be same as the Fulfillment's Deposit. Simple. I manually checked this (after setting up process builder) and is working fine, but when the trailhead app checks, it fails with the error : System.AssertException: Assertion Failed: Same value.

ISSUE: Now, if I see the debug logs (captured when Salesforce trailhead checks this). In below snippet (from debug logs) see the last 2 lines.

There is assertEquals which checks deposit and unitprice – Match.
But assertNotEqual is also checking deposit and unitPrice. It fails here. Both the values will be same, the assertNotEqual is failing because both the values are same!

Execute Anonymous: OpportunityLineItem oli1 = new OpportunityLineItem(OpportunityId=opp.Id, UnitPrice=2, quantity=1,pricebookentryid=pbe.Id, servicedate = date.newInstance(2050, 1, 1), explorer__c = sam.id);
Execute Anonymous: OpportunityLineItem oli2 = new OpportunityLineItem(OpportunityId=opp.Id, UnitPrice=2, quantity=1,pricebookentryid=pbe.Id, servicedate = date.newInstance(2010, 1, 1), explorer__c = sam.id);

Execute Anonymous: // make sure the deposit matches the unit price
Execute Anonymous: System.assertEquals(f1.deposit__c, oli1.unitprice); // one way in the future
Execute Anonymous: System.assertNotEquals(f2.deposit__c, oli2.unitprice); // one way in the past

How to fix this? Is this a bug?

Best Answer

Not a bug per-se, this is exactly the point of assertNotEquals... if the parameters ARE NOT EQUAL it returns true. Else, it returns false.

You answered yourself in your question:

"Both the values will be same, the assertNotEqual is failing because both the values are same!"

Exactly right, as it should.

See the docs for more information: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_methods_system_system.htm

But if you are asking "is this a bug w/ the trailhead validator", then perhaps it may be. You don't control their assertions, the assertions they have hardcoded into their validation engine when you click and check your answer after finishing a trailhead module.

Related Solutions

[SalesForce] Test class: Assertion Failed

You can use this for create a test user, in your test method.

    User u = new User(
                   FirstName = 'test',
                   LastName = 'test',
                   UserName = 'test@test.com.asdf',
                   Email = 'test@test.com',
                   ProfileId = UserInfo.getProfileId(),
                   Alias = 'TEST',
                   CommunityNickname = 'test.test',
                   EmailEncodingKey = 'ISO-8859-1',
                   LocaleSidKey = 'es_ES',
                   LanguageLocaleKey = 'en_US',
                   TimeZoneSidKey = 'Europe/Paris',
                   IsActive = true
                );
   insert u;

Can you tell us what is doing your trigger? i dont understand your assertion.

[SalesForce] System.AssertException: Assertion Failed: Expected: 2, Actual: 3

Don't follow the example set by this code.

The syntax is system.assertEquals(expected_value, actual_value, message).
- In the assertions above, expected_value and actual_value are flipped.
- While the message argument is optional, it is highly recommended and might have helped you here.
When using magic numbers in your unit tests, you can give them more meaning by making them constants. Most of my test classes have a line static final Integer RECORD_COUNT = Limits.getLimitQueries() + 1, which you could use in place of 3.
You aren't even testing the setManualShareAfterInsert method. You're testing a trigger somewhere, which you haven't shared with us.
Same goes for the setManualShareAfterUpdate method.

I can't tell you how to get your unit test working. I can't even tell if your code should work as advertised. But you might have some luck by working on Separation Of Concerns. You could break out a few discrete tasks and verify they work as expected, then build on that. The key to unit testing is to test small units of code.

I have found trying to build on top of code that tries to do dozens of things in one method is just not tenable. Here's a start for how I would refactor:

public static Set<Id> pluckIds(String field, List<SObject> records)
{
    Set<Id> ids = new Set<Id>();
    for (SObject record : records)
        ids.add((Id)record.get(field));
    ids.remove(null);
    return ids;
}
public static Map<Id, Accreditation__c> getAccreditations(List<Accreditation_Sales_Contact__c>  records)
{
    return new Map<Id, Accreditation>([
        SELECT Id, Name, Account__r.Partner_Community_User_Role_ID__c
        FROM Accreditation__c
        WHERE Id IN :pluckIds('Accreditation__c', records)
    ]);
    // if you query the Account__r.Partner_Community_User_Role_ID__c field,
    // you don't even need to query Account at all, just reference this way
}

Anyway, that's probably not the answer you were looking for, but hopefully it will help you to some extent.

Best Answer

Related Solutions

[SalesForce] Test class: Assertion Failed

[SalesForce] System.AssertException: Assertion Failed: Expected: 2, Actual: 3

Related Topic