A couple of weeks ago I posted a question in the ABAP Testing and Troubleshooting forum about using transaction SAT for testing class performance. I wanted to test the runtime of class methods without using a transaction, program, or function module. The answers to my question were clear:
Let me start by describing why I want to do this in the first place. My idea is that all developers should create performance reports for their class methods. Whenever a method is changed or enhanced by someone a new performance report is created and it is possible to review the performance and memory impact of the update. This should be done in a simple manner so that it does not require too much effort. Writing a program or a transaction for all methods just to performance test them does not seem feasible. Furthermore, many SAP customers do not allow creating objects that are not intended for productive use, which for obvious reasons excludes test programs and transactions. Please note that performance analysis of class methods is an addtion to traditional runtime analysis of transactions and programs, not a replacement.
Inspired by Hermann Grahm’s blog ST12 - tracing function modules, I decided to see how this concept works with transaction SAT and class methods. It is described in the following step-by-step guide in section 1-7.
By now, you probably wonder when ABAP Unit is getting into the picture. Now!
One problem with performance testing is when you are not using the same test data. Simply executing a method by pressing F8 and entering arbitrary test data will make it difficult to compare two test results. Full scale regression, integration, and acceptance testing covers these aspects. But here the focus is on unit testing. In most cases there is no test data repository for simple unit testing. Or is there? ABAP Unit!
I always write ABAP Unit for my methods. By using ABAP Unit when performance analyzing class methods, I can ensure that the test data remains the same or at least it will be similar when doing future changes. This makes the test results more comparable. Lets get our hands dirty and see how it is done.
Start by opening transaction SAT and create a variant with the settings described in Olga Dolinskaja 's blog Next Generation ABAP Runtime Analysis (SAT) – How to analyze performance. In addition to the variant settings, make sure to check the option "Explicit Switching On and Off of Measurement" as shown in the screenshot below.
The ABAP Unit framework uses a multitude of classes. Add your class in the "Program Components" part of the variant setting to make the measurement result simpler.

Enter SE80 in the transaction field of the "In Dialog" section.
Press the "Execute" button.

In SE80, make sure that the "Repository Browser" is selected and that the class you want to test is displayed. Now you can switch on the runtime analysis by selecting "Switch On" via the menu "System->Utilities->Runtime Analysis".

After switching on the runtime analysis, run the ABAP Unit test by righ-clicking on the class and choosing "Test->Unit Test".

Assuming that the ABAP Unit test ran successfully the measurement can now be switched off via the menu "System->Utilities->Runtime Analysis" or by pressing the "Cancel" button
.
The measurement results are displayed.

Switch to the "Programs" view to display the class specific measurements.

Check the class you want to analyze and select "Display Subareas in Time tool".
The performance result of the method CAT_SAYS is 3 microsec. Keep in mind that normally ABAP Unit would call numerous methods and these would then also be displayed. This result can now be stored by the developer. Next time the method is updated it is easy to compare the new performance with the old result.
This blog covers performance analysis, but can easily be enhanced to also cover memory analysis. All you have to do is change the variant in Step 1 as described in Next Generation ABAP Runtime Analysis (SAT) – How to analyze memory consumption.
It would be great if SAP added an option to do runtime analysis directly when executing ABAP Unit tests. Especially when the tests are triggered from the coverage analyzer.