Testing Function Modules

There are various situations in which you might need to test or use function modules:

·        As a unit test, where you test a single function module.

·        As a backend process, where you test a string of function modules that make up a whole process, passing the results of one module onto the next. You can do this in a single script or by chaining together several test scripts.

·        As utilities within a script, for example, to retrieve data from the database that you want to use in transactions, or to perform a complex plausibility check for which you know that a function module already exists.

The eCATT command to call function modules is FUN. The command interface corresponds to the interface of the function module. In the structure editor, it is divided up into sections for the various types of parameters – importing, exporting, changing, and tables – with a further section for the exceptions. To pass a value to the function module, assign the relevant literal or variable to the correct parameter in the command interface. Similarly, to get a value from an exporting parameter of the function module, assign a variable to it.

As well as assigning parameter values using the structure editor, you can also address the function interface programmatically in the command editor. This is useful if, for example, you want to assign values dynamically. In contrast, you cannot address the exceptions programmatically. The syntax is similar to the ABAP syntax for addressing complex structures. If you are working with internal tables, you must specify the relevant table index in square brackets. For example,

<Interface name>-TABLES-<table>[<index>]-<field name> = <value>.


Enclose FUN commands in MESSAGEENDMESSAGE blocks.


By default, a test fails if a function module throws an exception. For example, the function module ECATT_EXISTENCE_CHECK, which checks whether an eCATT object exists, can throw OBJECT_TYPE_UNKNOWN.

Sometimes, the aim of a test will be to make a function module throw an exception. In such a case, you will want the test case to be marked as successful if an exception is triggered. If you do not want a test to fail because of a particular exception, you can set a flag beside that exception in the structure editor. Then, irrespective of whether the exception occurs or not, the test will be marked as passed. That the exception occurred will still be recorded in the log. Every other exception will cause the test to fail.

You cannot use EEC_1-Exception-OBJECT_TYPE_UNKNOWN = 'X'. – you need to set the value in the structure editor.

Defining an exception as successful does not mean that the script will fail if the exception does not occur. If you want this to happen, you can query the special eCATT variable &EXCEPTION in the script. For example, in the above example, you would add the line: