Pillar 2 – asserterror

Goal: Understand what the asserterror keyword means and learn how to apply it.

A substantial part of the business logic we implement specifies conditions under which a user action or a process should fail or stop to continue its execution. Testing the circumstances that lead to this failure are as important as testing the successful conclusion of an action or process. The second pillar allows us to write tests that are focused on checking whether errors do occur; a so called positive-negative or rainy path test. For example, that posting errors out because a posting date has not been provided, or that, indeed, a negative line discount percentage cannot be entered on a sales order line. To achieve this, the asserterror keyword should be applied in front of the calling statement:

asserterror <calling statement>

Let's use it in a new codeunit and run it:

codeunit 60001 MySecondTestCodeunit
 {
     Subtype = Test;
 
     [Test]
     procedure MyNegativeTestFunction()
     begin
         Error('MyNegativeTestFunction');
     end;
 
     [Test]
     procedure MyPostiveNegativeTestFunction()
     begin
         asserterror Error('MyPostiveNegativeTestFunction');
     end;
 }

The MyPostiveNegativeTestFunction function is reported as a SUCCESS, and, consequently, no error message is recorded:

If the calling statement following the asserterror keyword throws an error, the system will continue executing the following statements. However, if the calling statement does not throw an error, the asserterror statement will cause one:

An error was expected inside an asserterror statement.

Where asserterror enables the test to continue with the next statement, it will not check the error as such. As we will see later, it is up to you to verify whether the expected did occur or not. If there is no verification on the specific error following the asserterror, any error will make your test pass.