In my tests I create an object and compare it to the one returned in the function using System.assertEquals. Despite all the properties being exactly the same I still get the "Assertion Failed" message when comparing objects.


System.AssertException: Assertion Failed: Expected: Attribute:[name=Name, options=null, required=false, showInUI=true, type=String, value=], Actual: Attribute:[name=Name, options=null, required=false, showInUI=true, type=String, value=]

Notice that Expected and Actual are exactly the same.

Note: all properties are primitive types except options which is a list of Strings.

  • Can you share the minimal code needed to reproduce this issue? The representation shown in a debug log message isn't always as informative as you might expect about the contents of your variables.
    – David Reed
    Commented Jul 25, 2018 at 12:50
  • 2
    If the object is an instance of a custom Apex class then you will need to implement equals and hashCode. Or better, if the check is only part of a test, implement a static equals method in the test class.
    – Keith C
    Commented Jul 25, 2018 at 12:53

1 Answer 1


I resolved this by overriding the equals method for my class as described in the documentation: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_collections_maps_keys_userdefined.htm

This is what it looks like:

public Boolean equals(Object obj){
    if (obj instanceof SchemaAttribute) {
        SchemaAttribute schemaAttrObj = (SchemaAttribute) obj;
        return required == schemaAttrObj.required && 
        showInUI == schemaAttrObj.showInUI && 
        name == schemaAttrObj.name && 
        value == schemaAttrObj.value && 
        options == schemaAttrObj.options && 
        type == schemaAttrObj.type;
    return false;
  • Just like @Keith C said. Commented Jul 25, 2018 at 12:55
  • In the Java world, implementing only equals and not hashCode is a very bad thing as when some future code that uses the objects in sets or maps is added everything breaks and it is not clear why. So I recommend putting this code only in the test so the core object contract is not broken.
    – Keith C
    Commented Jul 25, 2018 at 13:06

You must log in to answer this question.

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