This article is focused on ABAP developers in SAP ERP systems. It contains many platform-specific points that are of little interest or even controversial for developers using other platforms.

In smart books and articles a lot about it is written in general. But the question of specifics in ABAP programming is revealed little.

ABAP programming can be quite different. But in almost any large project, it can be decomposed into the following heaps:
')

• Exits (user-exits). These include validation, substitution, BTE (Business Transaction Events), BAdI, CMOD, and similar ways to extend standard functionality.
• Own application. It is likely that this will be a variation on the theme of CRUD.
• Reports. It can be said that a report is such an application of its own, but programs of this kind have their own nuances.
• Inbound integration, outbound integration. We call, we call, as it often does not match.
• Auxiliary libraries. Semi-finished products required for the construction of the finished product.

And now separately about exit.

Part one. First test

Exit is a separate class method or a function module of a well-defined interface with your ABAP code, which is called in certain business operations (transactions) at some specific moment. Like a plugin.

Classic case: functional replacement module without global data. And let the example be the event BTE 1120 (replacement when posting an accounting document).

In the case of exits, usually the test is to perform a user operation that is associated with this event. We could simulate this user operation, save the document, and then check this document for the required properties. But that’s one of the important differences between unit testing and standard testing, that you don’t need to act in this way.

We have a function module with several input parameters and several output parameters. We give something to the input, and we get some change at the output.

So our unit test should be like this:

• Prepare a set of input parameters that simulates the reference document we need
• we launch our function module
• check that the output parameters contain the required values

Suppose the original production was as follows:

If an accounting document of the type VB is posted and the positions are posted on the debit account 1080, then the entire document must be posted with the sign “Red reversal”.

TDD can also be applied, but we (for the time being) will not adopt such a methodology.

As a result, we wrote some code in FM ZFI_BTE_00001120:



The code is ready, we want to write a test for it now.

Option two:

• we start the master
• do everything handles

I think the master is made almost with a human face, fit.

First, we will look at the wizard, for this we go to the function group and then go through the menu “Create - Other objects - Generate test class” and go step by step.

A class is created not for a specific FM, but for a group of functions entirely:



You can come up with a name for the class and put some checkmarks:



We choose which functional modules we need:



Further, further, further ... We look that the master has generated for us:



The SETUP and TEARDOWN methods are empty. The engine will run them, respectively, at the beginning and at the end of each test.

For each selected function module, a test method was generated strictly by the name of our FM.

And the implementation of a basic check in the form of a simple call already exists:



As you can see, the master did not do anything supernatural, which means we can do such preparations ourselves.

If now we put a test around this code for our business scenario, then we come to the intermediate result:



I believe that it is not necessary to completely simulate the document, if it does not affect the work of the whole set of tests: it is enough to provide only the most necessary things for the work of the business scenario. Therefore, you can omit the date, amount, availability of the lender, account type and similar parameters.

It turned out a suitable working scenario, I plan to use in a combat situation.

You can throw tests for other functional modules in the group of functions.

Now we can run unit tests on the menu “Function module - Run - Module tests”:



Quiet, small, green, all is well. And if we were mistaken either in the test, or in the FM itself, the picture would be like this:



It broke! Q.E.D.

BTW: Here at last, there is an application to table functions! In my current active project, a big upgrade did occur, and now instead of the old APPEND and READ you can write such delicious things.

BTW: There is also a sub-item “Coverage Measurement” next to it, but we'll get to it.

BTW: Yes, there are flaws in the Russian version, we will not blame them.

For now, enough is enough ...
Continuation can be read here: Unit tests in ABAP. Part two. Rake