New Salesforce Assert Class

In the Winter 23 Salesforce release, the Assert Apex Class is new. It has many static methods that help provide clearer assertions within Apex test code. It was created so developers can write clearer and more maintainable test code. Let’s look at some examples to compare and contrast.

Expression True Assertions

Old Way

Boolean containsHello = 'Hello World'.contains('Hello');

system.assert(containsHello, 'The message does not contain Hello');

New Way

Boolean containsHello = 'Hello World'.contains('Hello');

Assert.isTrue(containsHello, 'The message does not contain Hello');

Equality Assertions

Old Way

Integer a = 3;
Integer b = a;

system.assertEqual(a, b, 'a and b are not equal.');

New Way

Integer a = 3;
Integer b = a;

Assert.areEqual(a, b, 'a and b are not equal.');

Not Null Assertions

Old Way

Object instance = create();

// Option 1
system.assert(instance != null, 'The instance is null.');

// Option 2
system.assertNotEquals(null, instance, 'The instance is null.');

New Way

Object instance = create();

Assert.isNotNull(instance, 'The instance is null');

Is Null Assertions

Old Way

Object result = calculate(input);

// result should be null for this given input.
system.assertEquals(null, result, 'The result is not null.');

New Way

Object result = calculate(input);

// result should be null for this given input.
Assert.isNull(result, 'The result is not null.');

Error Testing

Old Way

Exception expectedException = null;
try {
    // Do something here that should cause an exception
}
catch (Exception ex) {
    expectedException = ex;

    // Assert the expected error occurred and not a different one.
}

system.assert(expectedException != null, 'The expected error did not happen.');

New Way

try {
    // Do something here that should cause an exception

    Assert.fail('The expected error did not happen');
}
catch (Exception ex) {
    expectedException = ex;

    // Assert the expected error occurred and not a different one.
}

Observations

• After years of writing “system” before all the “assert” functions, the “system” became invisible. It was just something that was there out of necessity. It was not very clear. Starting with “Assert” is more intentional and revealing making the code cleaner.

• The Assert Class has many methods for all the common test assertion cases and they’re all better named than their predecessors. Some methods not mentioned in the examples are “isFalse”, “areNotEqual”, “isInstanceOfType” and “isNotInstanceOfType”.

• One of my testing best practices is to always have an assertion message. One reason for that is that sometimes that the assertion code isn’t always the clearest. With these better assert methods, one may consider not always putting in an assert message. I’m leaning towards continuing to always have it for consistency but the thought crossed my mind.

Recommendations

• When writing new test code or refactoring existing test code, use the new Assert methods instead of the former ones to make the code cleaner and more intentional.

• Don’t go out of your way to refactor the existing test code to just replace them with the new Assert methods. The developers have better things to do!

• Ensure the test code has asserts! Without them, the test code isn’t testing anything and is just there to satisfy the test code coverage requirement. The test code is to ensure the system behaves as expected! The 75% test code coverage requirement will naturally be met with good tests. Sadly, this is still common.

What are your thoughts on the new Assert methods and how will it change your test code?