In an earlier posting, I showed what the Test-Driven Development cycle might look like in the ABAP Workbench (SE80) in NetWeaver Release 7.01. Unfortunately, the TDD experience in that Release was marred by a hurdle right at the start of the process of implementing an ABAP class. That hurdle has been removed, and there are three other important improvements to ABAP Unit.

With NetWeaver 7.0 EHP2 (Release 7.02), the process has become a little bit more graceful. This weblog reviews what ABAP TDD looks like in practice in Release 7.02.  (Look for even more improvements in support for ABAP TDD in the Customer Engagement: Evaluation of the Pilot Version of ABAP in Eclipse.)

Start by assuming that you have just created a new, empty class in transaction SE80. You are looking at the form-based class builder, in change mode.   

1. You can now practice TDD orthodoxy right from the start: You can create ABAP Unit test methods before defining any methods in your global class under test. This means that you can evolve the signatures of your production methods in the course of testing from your test methods. This was not possible in Release 7.01.

   From the form-based class editor, choose Goto > Local Definitions/Implementations > Local Test Classes.

   The source code editor opens with the Local Test Classes include.

   Note: The ABAP Unit wizard is still available. As in 7.01, you can define the signatures of the methods of your global class first and then generate the ABAP Unit test methods from the signatures. Call the ABAP Unit wizard with Utilities > Test Classes > Generate (or Utilities > Test Class Generation, if you are working in the source-code based class builder).

2. Type in the definition of your ABAP Unit test class.

   Do you remember the ugly old pseudo comments for specifying the risk level and duration of ABAP Unit tests in Release 7.01?  In 7.02, these are replaced by arguments of the ABAP CLASS statement. This also means that you can use code completion to help with the definition of your ABAP Unit class:

   CLASS lct_test_it DEFINITION FOR TESTING RISK LEVEL HARMLESS DURATION SHORT.
  PRIVATE SECTION.
    METHODS test_add_it_up FOR TESTING.
...

3. In your test methods, type in the call to a method-under-test as you think it should be defined.

   With a double-click on the method name, you can define it via forward navigation in the global class that you are testing.

     method test_add_it_up.

    data result type i.

    result = cut->add_it_up(  “double-click on add_it_up
        addend_1 = 1          “to define the method in the
        addend_2 = 1 ).       “class under test

  endmethod.

   Forward navigation unfortunately does not automatically fill in the parameters of your new method.

   Even so, in 7.02 you can drive all of your development from your test methods, right from the start.

4. In your test method, assert the result that you want to see.  There is a new and improved standard class for this in Release 7.02, CL_ABAP_UNIT_ASSERT. Here’s an example:

      cl_abap_unit_assert=>assert_equals( act = result exp = 2 ).

5. Run your ABAP Unit test(s). The same convenient mechanism exists as in 7.01. From the ABAP Unit source code editor, choose Local Test Classes > Unit Test. 

   If the tests all run successfully, you see a success message in the status line of the SAP GUI.

   Otherwise, the ABAP Unit Result Display opens. You can navigate to the test method and then farther to the method under test, so that you can correct its implementation.

Mass Testing with the ABAP Unit Browser

Running a whole lot of ABAP Unit tests at once may not strictly be part of the TDD process. But it sure is useful for regression testing and verifying that your new code is still okay after you have transported it to the integration or consolidation system.

The ABAP Unit Browser – new with Release 7.02 – helps you with mass testing, both in the development system and in the consolidation or quality-testing system.

Activate the ABAP Unit Browser by selecting it in transaction SE80, in Utilities > Settings, on the Workbench (General) tab.  Among other options, you can run all ABAP Unit tests in a package or in the programs of a particular user. You can also store ‘favorites’, or defined collections of ABAP programs.  See the standard documentation for more information on the ABAP Unit Browser.

In the old R/3 days, ABAP programmers rarely needed to analyze memory consumption in their programs.  The simple and robust ABAP memory model made it very hard for anyone to program a serious ABAP memory leak.

With the addition of more types of dynamic memory objects – not just internal tables, but also strings, anonymous data objects, boxed components – and a trend toward transactions that live longer, it’s now possible to write an ABAP program that can run into memory problems.

Since ABAP programmers can no longer ignore memory consumption, the ABAP Workbench has greatly enhanced the memory analysis tools in the New ABAP Debugger and in the Memory Inspector (transaction SMI or S_MEMORY_INSPECTOR).

This weblog showcases the enhancements that come with EHP2:

• The Dominator Tree (or keep-alive tree) for containment hierarchies in memory objects – which runtime entity is keeping which memory object alive. This new analysis tool is offered in both the New ABAP Debugger and in the Memory Inspector. 
• The Memory Object Explorer in the New ABAP Debugger, for navigating up and down through the memory objects in the keep-alive hierarchy of objects. Starting from any memory object, you can navigate up to its parents or down to its children, and you can take a look at the contents of each memory object.
• A separate weblog shows you the new Application-specific memory analysis tools in the New ABAP Debugger – for looking at the memory consumption of ABAP Web Dynpro applications. There is also a similar tool for analyzing Web Service / HTTP applications.

You may also notice that doing memory analysis in the debugger is much more comfortable, and that we have made improvements in the user interface in the Memory Inspector as well. But we do not go into these UI changes in detail, nor will we look at the Memory Inspector transaction in this blog.

The New Features in Practice in the Debugger

You do memory analysis usually for one of two purposes:

• You want to see how big your program – or objects in it - are in terms of memory consumption. Is it bigger than you expect?  Usually you’re in the New ABAP Debugger when you do this.
• You want to see whether you have a memory leak. Does the memory consumption of your program change over time?  Or – how did it get so big that it dumped because of lack of memory – this question also sometimes comes up.

Usually, you’re comparing memory snapshots in the Memory Inspector (transaction SMI) when you’re doing this type of analysis.

Let’s see how the new memory analysis features work if you are in the debugger, just checking how much memory your program uses. Maybe you’re just being cautious in doing this checking – or maybe you’ve learned:  a long-running transaction or service with lots of dynamic memory objects means, you better check the memory consumption before your customers find out about it for you.  What you see here on the new memory analysis features applies just as well in the separate Memory Inspector transaction.

A Comfortable Quick Look at Memory Consumption – The Memory Analysis Tab

You don’t have to switch to a memory analysis tool anymore to see how much memory objects in your program are using.  There’s a new Memory Analysis tab in the new ABAP Debugger, on the Variable Fast Display. Just switch to the tab, click on a variable in your program, and you can see how much memory the object uses.

Here we have two tables that have the same number of rows, and we happen to know that they contain the same data - except that IT_CUSTOMERS contains extra data.  Even so, IT_CUSTOMERS is smaller in memory.  How is the difference explained?   Does IT_CUSTOMERS offer a more efficient way to organize the table?  A closer look shows that we don’t understand how IT_CUSTOMERS is organized. The table statistics don’t seem to match the memory size.

• The size of table IT_SCUSTOM is okay – 4637 rows of 16 fields with a row-length of 464 bytes is close to the Bound Used Memory (bound memory is the memory that would be freed if the table were cleared) plus some management overhead.   The table simply is that big.
• The size of IT_CUSTOMERS is puzzling. It has the same number of rows as IT_SCUSTOM but a row length of 32 bytes. No way that the table body itself comes close to 1.7 million bytes of bound memory.

Analyzing Table IT_CUSTOMERS with the Memory Analysis Tool

To study table IT_CUSTOMERS, you activate the Memory Analysis Tool by choosing the New Tool or Replace Tool button, opening the Memory Management folder, and clicking on Memory Analysis.

The tool that was available before EHP2 was the Memory Objects view, shown below in its form in NetWeaver 7.0 EHP2. This tool shows you the memory objects of the program (the representations of dynamic variables in the memory management system) ranked by size. 

Memory Objects also shows you which variables reference each memory object.  But the view does not help us to understand the differences between the IT_CUSTOMERS and IT_SCUSTOM tables. Essentially we just have an unstructured list of memory objects ranked by size.

Here’s where the new Dominator Tree view (below) shows how useful it is.  In this view, it’s immediately clear how IT_CUSTOMERS is structured. The rows are so short because they contain only an object reference. The CUSTOMER objects in the table contain, by the way, a further object, ACCOUNT.  The CUSTOMER objects are also keeping several strings – variables NAME, ADDRESS, and CITY - alive.  The bound storage of the table is so high because the table is keeping all of the customer object hierarchies alive.  (Without the references from IT_CUSTOMER, the ABAP garbage collector would clear the objects away and free the memory.)

The organization of the table is now clear. Where does the advantage in memory use of the IT_CUSTOMERS table come from, compared to table IT_SCUSTOM? 

To find the answer, you could copy the name of a CUSTOMER object into the clipboard, and start the Memory Object Explorer (available only in the debugger, not in the Memory Inspector). In the Memory Object Explorer (below), we can follow edges from the CUSTOMER object to its children, all of the objects that it references.

The Dominator Tree shows only strings and instances of classes that belong to the bound storage of each CUSTOMER class object. These are the objects that CUSTOMER keeps alive. The Memory Object Explorer, by contrast, also shows objects that are referenced by more than one CUSTOMER instance, memory objects that are in effect shared. Can it be that sharing of objects accounts for the reduced storage use?

We follow a CUSTOMER object to its referenced objects and then check some of the referenced objects themselves in the Explorer. COUNTRY looks like a good variable to check for sharing among multiple CUSTOMER objects. So we go from string {S:S9} ADDRESS-COUNTRY up the memory hierarchy – Higher-Level Memory Objects - to see the parents of this string, objects that reference this string.

And in fact, as you can see below, the more efficient storage use in table IT_CUSTOMERS than in IT_SCUSTOM could be due to massive sharing of string objects in memory.  There are many CUSTOMER objects from our table that reference the same COUNTRY string.

The IT_CUSTOMERS table design takes advantage of the fact that string variables that have the same content share a single memory object.  (See ‘value semantic’ in the ABAP Online Help (transaction ABAPHELP or at help.sap.com).  ABAP gives a string or other value-semantic object its own memory object only on an as-needed basis – if the string is changed.

In many applications, a table like this list of customers is rarely changed, but is used instead to guide processing. In this case, it may make sense to make use of memory object sharing to reduce storage consumption.  In this application, CUSTOMER attributes like the country-of-residence reference the same string, as long as the same country is being referenced.  You can check out whether the strategy is really worthwhile – when filling a table, when reading a table, in the event that object attributes are changed – by doing some testing of the alternatives in the ABAP Runtime Analysis, transaction SAT. (See the weblogs by Olga Dolinskaja on the new SAT.)

An advantage of doing memory analysis in the debugger is that you can see what the value of the variables is. This is something that you cannot do when you analyze memory snapshots in the Memory Inspector (transaction SMI).  A double click on string {S:S9} above shows us what country all of those customers inhabit:

But the Memory Inspector, in turn, has the advantage of being able to compare memory snapshots and show changes in memory use over time. That’s an invaluable capability for checking for leaks in a long-running ABAP application.

Create an RFC breakpoint.  Setting a breakpoint on the ABAP Command ‘RFC’ tells the Debugger to run the script every time an RFC call is made.

• Then switch to the editor and position the cursor in the SCRIPT method, where you see

+*** insert your script code here+   me->break( ). You’ll probably want to comment out the BREAK instruction. If you wish to, you can have the script run it when it encounters bad data returned by an RFC. You can stop the program that you are debugging and use the debugger to look at the problem more closely. You could call that an ‘intelligent Debugger Script breakpoint’. Since the script runs whenever an RFC call is to be made, we’ll need this logic: 0.1. Run a debugger step to execute the RFC call 0.2. Read the variable or variables that we want to check 0.3. Apply tests to the value of the variable(s) – our own ‘application logic’, so to speak. 0.4. If we find bad data, write a user-defined trace message, stop with a debugger breakpoint, or do both actions. Insert the first instruction – running the RFC function call – by using the Script Wizard to insert this debugger method call:   As you can see, the method signature lists the constants for the different types of debugger steps and jumps. We also uncomment the TRY and CATCH statements inserted by the Wizard. +*  me-> break( ).+
+*************************************************+
+* debugger commands (p_command):+ +* Step into(F5)   -> CL_TPDA_SCRIPT_DEBUGGER_CTRL=>DEBUG_STEP_INTO+ +* Execute(F6)     -> CL_TPDA_SCRIPT_DEBUGGER_CTRL=>DEBUG_STEP_OVER+ +* Return(F7)      -> CL_TPDA_SCRIPT_DEBUGGER_CTRL=>DEBUG_STEP_OUT+ +* Continue(F8)    -> CL_TPDA_SCRIPT_DEBUGGER_CTRL=>DEBUG_CONTINUE+
+*************************************************+
+****************************************************************+
+*Interface (CLASS = CL_TPDA_SCRIPT_DEBUGGER_CTRL / METHOD = DEBUG_STEP )+
+*Importing+
+*        REFERENCE( P_COMMAND ) TYPE I+
+****************************************************************+     TRY.         CALL METHOD debugger_controller->debug_step           EXPORTING             p_command = cl_tpda_script_debugger_ctrl=>debug_step_over.       CATCH cx_tpda_scr_rtctrl_status .       CATCH cx_tpda_scr_rtctrl .     ENDTRY. 0.1. Then add the second element of the script logic: A debugger method call to read a variable that is to be checked. Here, we use a variable from the RFCSI structure returned by the special RFC call RFC_SYSTEM_INFO, which requires no logon. This is a convenient way to simulate the error that occurred at the customer site. Again, most of what we need is a debugger wizard call from the +Script Wizard+. We need to add a variable declaration to receive the value read by the debugger. The type information for the declaration is given to us in the method signature inserted by the Wizard. Note that the names of variables in the debugged program must be in capital letters.      DATA rfc_host TYPE tpda_var_value.     TRY.         CALL METHOD cl_tpda_script_data_descr=>get_simple_value           EXPORTING             p_var_name  = 'SYSTEM_INFO-RFCHOST2'           RECEIVING             p_var_value = rfc_host.       CATCH cx_tpda_varname .       CATCH cx_tpda_script_no_simple_type .     ENDTRY. We might want to report exceptions with trace method calls after the CATCH instruction, for example if we wrote the variable name incorrectly in P_VAR_NAME. 0.1. The third element of the script is a little bit of logic to check whether SYSTEM_INFO-RFCHOST2 contains valid data. That might look like this:     DATA length_of_hostname TYPE i.     DATA target_destination TYPE rfcdest.     DATA my_trace TYPE tpda_trace_custom.     length_of_hostname = strlen( rfc_host ).     IF length_of_hostname = 0 OR        contains( val = rfc_host(length_of_hostname) regex = '[^[:word:]]' ). We want to check that a hostname was returned and then that the hostname contains only the alphanumeric characters that we expect. By the way, the program DEMO_REGEX_TOY, featured in a weblog by Horst Keller, is a useful tool for testing your REGEX expressions. 0.1. The final element of the script is a trace message in the event that the script finds bad data returned by an RFC call. We could also insert an me->break( ) to stop at the scene of the crime as well. We would want to add a second GET_SIMPLE_VALUE() call in order to report the name of the RFC destination, if we are not stopping to examine the situation directly. The user-specific trace message – written with method ADD_CUSTOM_INFO() requires only text in the VALUE field of the TPDA_TRACE_CUSTOM structure required by the method.       TRY.           CALL METHOD cl_tpda_script_data_descr=>get_simple_value             EXPORTING               p_var_name  = 'LS_ALSYSTEMS-DESTINAT'             RECEIVING               p_var_value = target_destination.           CONCATENATE 'This destination returns bad data:'                       target_destination                       INTO my_trace-value SEPARATED BY space.           CALL METHOD trace->add_custom_info             EXPORTING               p_trace_entry = my_trace.         CATCH cx_tpda_varname cx_tpda_script_no_simple_type.           my_trace-value = 'Error in script'.           CALL METHOD trace->add_custom_info             EXPORTING               p_trace_entry = my_trace.       ENDTRY.     ENDIF.   ENDMETHOD.                    "script 0.1. Save the script (remember to use a naming convention so that you can load the script easily).  It is ready to use in the debugger.  The output might look like this:   You can also download the script to file so that it is available for uploading into other systems, should RFC problems occur elsewhere. h3. Script-Writing Notes Here are some tips that may help you to create scripts more quickly and efficiently. h5. Short Dumps The ABAP debugger infrastructure intercepts fatal errors in debugger scripts. A short dump is reported as a message in the status line of the debugger and does not propagate to a full-fledged short dump. For example, the script coding:    DATA my_quotient TYPE I.   my_quotient = 1 / 0. …produces this message rather than a short dump.   

Don't miss the presentation on Test-Driven Development in ABAP at TechEd 2010! 

At design time or when you refactor code, you can enable better unit testing by allowing dependencies to be injected into your code. Your ABAP Unit tests can then substitute test doubles for the production entities wherever you have enabled dependency injection.

This weblog shows how you might set up private injection of dependencies in ABAP. This is a useful pattern if you do not want to expose critical dependencies to users of a class, as you might do with Managing  Dependencies in TDD: Constructor Injection in ABAP in EHP1.

If you declare a local test class to be a LOCAL FRIEND of the class under test, then the test class can access protected and private components of the class. This is useful if the test class should test private and protected methods. But it also allows the test class to inject dependencies that are declared as private attributes of the class under test.

Private injection by a local friend allows you to break dependencies but still protect them from manipulation from outside the class under test.

Here is some sample code showing what private injection might look like:

*----------------------------------*
* In CLASS_UNDER_TEST...
*----------------------------------*

*----------------------------------*
* The dependency needed by
* CLASS_UNDER_TEST is instantiated
* in the CONSTRUCTOR method. The
* constructor sets the private variable
* MY_DEPENDENCY to reference the
* depended-on object.
*----------------------------------*
CLASS class_under_test DEFINITION CREATE PUBLIC.
  PUBLIC SECTION.
    METHODS constructor.
    METHODS method_under_test
      RETURNING
        value(useful_value) TYPE i.
  PRIVATE SECTION.
    DATA my_dependency TYPE REF TO if_my_dependency.
ENDCLASS.

CLASS class_under_test IMPLEMENTATION.
  METHOD constructor.
    CREATE OBJECT my_dependency
      TYPE REF TO cl_my_dependency.
  ENDMETHOD.

  METHOD method_under_test.
    useful_value = my_dependency->calc_value( ).
  ENDMETHOD.
ENDCLASS.


*----------------------------------*
* In the local ABAP Unit include
* Goto -> Local Definitions/
* Implementations -> Local Test
* Classes...
*----------------------------------*

*----------------------------------*
* There is a local test double class
* that reimplements IF_MY_DEPENDENCY
* for use in testing.
*----------------------------------*
CLASS ltd_test_double DEFINITION.
   PUBLIC SECTION.
      INTERFACES if_my_dependency.
      ...
ENDCLASS.

CLASS ltd_test_double IMPLEMENTATION.
   METHOD if_my_dependency~calc_value.
       r_value = 1.
   ENDMETHOD.
ENDCLASS.

*----------------------------------*
* LTC_ABAP_UNIT_TESTS is declared as
* a LOCAL FRIEND of the class under
* test. As a LOCAL FRIEND, the test
* class can access protected and
* private members of CLASS_UNDER_TEST.
*----------------------------------*
CLASS ltc_abap_unit_tests DEFINITION DEFERRED.
CLASS class_under_test DEFINITION
   LOCAL FRIENDS ltc_abap_unit_tests.

*----------------------------------*
* In LTC_ABAP_UNIT_TESTS, the test
* method substitutes a test double for
* the production object referenced
* by the private attribute MY_DEPENDENCY
*----------------------------------*
CLASS ltc_abap_unit_tests DEFINITION FOR TESTING
"#AU DURATION SHORT
"#AU RISK LEVEL HARMLESS
PRIVATE SECTION.
  DATA:
     cut TYPE REF TO class_under_test.
  METHODS: calc_value_test FOR TESTING.
ENDCLASS.

CLASS ltc_abap_unit_tests IMPLEMENTATION.
  METHOD calc_value_test.
     DATA: useful_value TYPE i,
               test_double TYPE REF TO ltd_test_double.

     CREATE OBJECT test_double.
     CREATE OBJECT cut.

     cut->my_dependency = test_double.
     useful_value = cut->method_under_test( ).

     cl_abap_unit_assert=>assert_equals(
        act = useful_value
        exp = 2 ).
  ENDMETHOD.
ENDCLASS

Here is how the sample code works:

• Instead of creating depended-on objects (dependencies) inline in its code, CLASS_UNDER_TEST in the sample does the following:
  • It declares dependencies as PROTECTED or PRIVATE attributes.
  • It instantiates these depended-on objects outside the methods that actually use them. In this case, the CONSTRUCTOR does the instantiation.

    The instantiation of depended-on objects is hidden from users of CLASS_UNDER_TEST.

• A local helper class - LTD_TEST_DOUBLE in the sample code - provides a test version of the IF_MY_DEPENDENCY object used by CLASS_UNDER_TEST.
• In the ABAP Unit test class - LTC_ABAP_UNIT_TESTS in the sample code - the test method creates an instance of the test double. It also creates an instance of the CLASS_UNDER_TEST, and substitutes the test double for the production MY_DEPENDENCY object for use in testing.

An alternative to cluttering up the test method with the instantiation of the test double and CUT test object would be to do these tasks in the ABAP Unit SETUP and TEARDOWN tasks.

Perhaps you know some of the trademark slogans of test-driven development, like 'Red. Green. Refactor' or 'Test a little, implement a little, reflect a little.' 

In TDD, reduced to its basic work cycle, you write a unit test and run it. The test fails because the code under test is not implemented.  So you implement the code under test such that the unit test is green. Then you repeat the cycle until eventually the method under test and the entire class are completely developed, completely documented, and completely testable (using all of the unit tests you have developed along the way).

As a purely practical matter, how do you translate the TDD work cycle into ABAP development with ABAP Unit in the ABAP Workbench?  This weblog shows what ABAP TDD in the Workbench in NetWeaver Release 7.01 (7.0 EHP1) might look like. 

We aren't talking rocket science here, of course. But the idea is to save you some time and fumbling around the first time that you try to practice TDD in the Workbench.

If you don't know ABAP Unit, then you won't get very far with TDD until you know a little about it.  Here, you'll find a sample ABAP Unit implementation in the NetWeaver 7.0 documentation: http://help.sap.com/saphelp_nw70/helpdata/en/a2/8a1b602e858645b8aac1559b638ea4/frameset.htm

So what does practical TDD look like in the ABAP Workbench? We'll talk only about classes (you do develop only classes nowadays, right?  See ABAP Programming Guidelines, actually - Modern ABAP Programming - by Horst Keller and Wolf Hagen Thümmel.)

So, you create a brand new class in SE80 in the ABAP Class Builder. What next?

1. Ideally, you would like to write your first ABAP Unit test method and then go from there.

   Here, we have to adapt TDD to the Workbench.  In NetWeaver 7.01 (7.0 EHP1), you'll first need to define the signature of a method to test.  There is no way to create an ABAP Unit include without a production method as a starting point. (This is fixed in EHP2.)

   So go ahead and define the signature of the first method in your class under test.  (You may want to keep on defining production method signatures first, since you can't define a method via forward navigation from a test method.)

2. Create the ABAP Unit include by choosing Utilities -> Test Class Generation. You'll see the little dialog shown below. You can tell ABAP Unit to generate test methods for the production methods you specify. Choose all of the options - you'll save yourself some typing. 

    

You'll find yourself in the class editor, ready to define your ABAP Unit test method.   

After this initial create-include step, you can edit your ABAP Unit class by choosing Goto -> Local Test Classes.  Or, if you are lazy, you can call Test Class Generation again and tell it to create a test method for whatever new production method you have just defined.

3. Implement your test class. Usually, ABAP Unit test classes are local classes in the class pool of a global class.

What is an ABAP Unit test class?  Simply a class definition with the FOR TESTING option, together with method definitions that also have the FOR TESTING option. And then method implementations with calls to CL_AUNIT_ASSERT to evaluate the tests.

CLASS abap_unit_testclass 
     DEFINITION FOR TESTING. 
     "#AU duration short      
     "#AU risk level harmless
  PRIVATE SECTION.
   METHODS test_toggle_value FOR TESTING.
   DATA m_ref TYPE REF TO cl_class_under_test.
   METHODS setup.      "Set up a fixture
   METHODS teardown. "Clear away a fixture.

ENDCLASS.                    "abap_unit_testclass DEFINITION

CLASS abap_unit_testclass IMPLEMENTATION.
  METHOD setup.
      CREATE OBJECT m_ref.
  ENDMETHOD.                   "setup

  METHOD test_toggle_value.
      DATA: test_value TYPE i.

      m_ref->toggle_value( CHANGING toggle_value = test_value ).
      cl_aunit_assert=>assert_equals( exp = 1 act = test_value ).

      m_ref->toggle_value( CHANGING toggle_value = test_value ).
      cl_aunit_assert=>assert_equals( exp = 0 act = test_value ).

 ENDMETHOD.                    "test_toggle_value
ENDCLASS.                    "abap_unit_testclass IMPLEMENTATION

4. The big moment has arrived. Activate the entire class. Then choose Class -> Unit Test or the appropriate entry from the class context menu. Or just Local Test Classes -> Unit Test from the test class editor to run the ABAP Unit tests. Of course, your empty TOGGLE_VALUE method will fail the unit test miserably, and ABAP Unit will branch to a results display like this one.



With F3 you can leave the ABAP Unit results display and return to the Class Builder.  Or you can jump from the ABAP Unit results display to the test method and from there to the production source code. There, you can implement TOGGLE_VALUE such that it passes the ABAP Unit test. And then you can start over, casting the next requirement on the method or the class in an ABAP Unit test method.

Coming up: Managing Dependencies for ABAP Unit testing

The first part of this weblog did not quite manage to open a short dump as of Release NW04s 7.0 EHP1 for display. Instead it reviewed ways to extract contextual information from the short dump lists and elsewhere.

In this second part of the web log we, in the words of W. C. Fields, grab the bull by the tail and face the issue.  In a short dump, you want to answer these primary questions:

• What exactly happened?
• Where did it happen?
• How can the problem be corrected? 

We will look at the diagnostic information and aids that the short dump offers for answering these questions.

From the Top: The Context of the Error

You have finally made it into one of the ABAP short dumps. You'll see a display that looks quite similar to this one.

Maybe the Short text , What happened, Error Analysis, and Source Code Extract will be enough to let you diagnose and correct the problem. That's often the case when a dump was caused by a relatively stupid programming error. But let's take it from the top and see what diagnostic help the short dump offers, just in case.

The Short Dump Heading

On a bold red background at the top of every dump you will find the short dump ID and the date and time at which the dump occurred.  Together with the Application Server and the WP Index from the dump list, you have all the information that you need to look for relevant messages in the ABAP System Log or Developer's Trace (see Part I of this weblog). 

If an exception occurred and the runtime error was cacheable, the exception that caused the dump is also shown. 

Together with the program name (ZSP_COMPLETE_FQDNS) from What happened?, you also already have enough information to search for a relevant OSS note.  The combination of dump ID or exception name and program name should find the right note, if it exists. You'll also find a more extensive list of search terms for the OSS in the How to correct the error section in the dump.

The System Environment: Context Information and Where Did That RFC Actually Come From?

You probably skip over the context information presented under System Environment. But there are some worthwhile nuggets of information in there.

If you plan to search for OSS notes and messages, then you will need the system release and SP levels, kernel patch level, and other facts on the ‘scene of the crime' to see whether notes or messages fit your problem.  If you plan to open an OSS message for SAP, then you can simply save and attach the entire short dump. (From the dump display in ST22, choose System -> List -> Save -> Local file.) That should help Support to respond quickly to the problem.

If you are analyzing the problem yourself, then here are three important bits of information:

• At the bottom of the System environment list, you'll find a compact overview of the memory usage of the program at the time that it dumped. If you see that the program has allocated heap memory, then check to see in section Information on where terminated to see if the program was started in a background job. If the program was not running as a background job, then you might want to take a look at the memory consumption of the program in the Debugger with the Memory Analyzer or with the ABAP Runtime Analysis (transaction SAT).  A dialog program - one running interactively in a dialog process - gets heap memory - private, process-local memory - only if the memory resources of the Web AS have been exhausted. (Just to confuse things, background jobs manage memory differently, and get heap memory before getting ABAP Extended Memory.) If you see a dialog program with heap memory, then something is wrong with the program. Or the memory resources configured in the Web AS are inadequate.  Or possibly other processes are memory hogs and have forced this process into heap memory.
  
• Check the User and Transaction section to see if the dump occurred while processing a dynpro screen. The User and Transaction list specifies the screen and ‘Screen Line' at which the dump occurred. Screen Line is actually the line in the flow logic of the dynpro at which the faulty module was called. You'll also get this information out of the Source Code Extract as well, but here, you won't have to piece together the information on which module in which dynpro in which program failed.
  
• If you are dealing with an RFC problem in the RFC server, then the Server-Side Connection Information tells you where the RFC call came from. You can then find the short dump on the caller side, which may help you to understand the server-side dump.

And of course, the opposite is true. From a dump on the client side of an RFC interaction, you can find out where the call went.

What Happened Exactly:  Short Text, What Happened, Error Analysis

The key question is: what happened exactly?  You need to understand the problem in detail to be able to correct it. For this understanding, the Short text, What happened, and Error analysis sections are invaluable.

The Short text states what happened in a single line. In our MOVE_TO_LIT_NOTALLOWED_NODATA dump (above), the short text is this:

Interesting - so I'm trying to overwrite a constant in my program? 

The What happened section of this dump adds the name of the program in which the error occurred. 

In the screen shot above, the identification of the faulty program is quite simple, since I was too lazy to write a faulty method that perhaps resided in a separate include.  But you may see more complicated explanations of the location of the error like this:  

• The termination occurred in the ABAP program "SAPLSVIM" in "VIM_BC_LANGU_ADD". The main program was SAPLS_IMG_TOOL_5. The termination occurred in line 330 of the source code of program LSVIMF59. In this case, SAPLSVIM is the current program, in which the dump occurred, and the SAPL prefix indicates that we are actually talking about the function group SVIM. VIM_BC_LANGU_ADD is the processing block (function module, method, form routine) in which the dump occurred. LSVIMF59 is the name of the include in which VIM_BC_LANGU_ADD is located.
  
• Or, if the crash occurred in a class, you might see something like this: The current ABAP program "CL_IM_SPROXY_BADI_CTS=========CP" had to be terminated because ..., where  CL_IM_SPROXY_BADI_CTS=========CP is the name of the class pool in which the dump occurred. You can enter the full name in SE80 or SE24 to display the class, but more commonly, you would simply enter CL_IM_SPROXY_BADI_CTS...

In many short dumps with few possible causes, the What happened section describes the error that occurred quite exactly.  The MOVE_TO_LIT_NOTALLOWED_NODATA dump, however, can arise out of many different circumstances.  It's not possible to say which transgression in the code produced the short dump, so detailed explanations are forced from What happened into the next very useful section, the Error Analysis.

Short dump texts are written by SAP kernel developers. The Error analysis sections often provide really detailed information about the possible causes of a short dump, which in turn reflects the detailed knowledge of the kernel that these developers have.  There is often a lot of text, but the time taken to read it through will be rewarded.

For example, we learned from the short text that my program dumped because it tried to overwrite a constant. I don't see any constant in the bad code below.  I just wanted to complete the fully-qualified domain names of a list of hosts.  Do you see the error in the code? 

If you don't see where I try to overwrite a read-only field, then see the seventh point in the discussion in Error analysis, the one that begins "Accesses using field symbols..."  Experience has shown that a lot of people just skip over the explanations in What happened and Error analysis.  This may end up costing them more time than it saves.

Where Did It Happen:  Source Code Extract

The SAP Short Dump developers were right to put Source Code Extract in initial caps, because, if you are lucky, this is a really nice, helpful section of the dump.  You're shown exactly where the program was aborted.  A few people don't know that from here, you can jump right into source code in the ABAP Editor with a double-click.   In the dump that we have been following, it would be possible in the editor to branch to the definition of the internal table LT_CSMNSDIC, where you might notice that the CDNSNAME field has been declared as part of the key of the sorted internal table...

If you can reproduce the problem, then you can set a breakpoint right from the short dump in order to stop just before the short dump occurs. You can then use all of the tools of the new ABAP debugger to investigate the cause of the dump.

If the code line shown by the pointer doesn't seem to make any sense in the context of the dump, then take a look at the previous line of code.  Occasionally, the instruction counter may still advance even after a dump has been triggered, so that the >>>>>> pointer points at the line following the bad line of code. 

Where Did It Happen: Active Calls/Events

In program failures that involve infrastructure like Web Dynpro, or calls between components, or in which an uncaught exception has been passed up through the callers, the Active Calls/Events section may help you to understand the components involved in the crash.  This call stack is a useful supplement to the point of failure marked in the Source Code Extract, because in the stack you can see how you got to the point of failure.  

You read the Active Calls/Events list from the bottom up.  It shows all of the report events, dynpro modules, functions, methods and form routines through which the path of execution has come.  You can jump into the ABAP Editor at any level in the call stack. This means that you can set breakpoints all along the way to the dump if you think that a problem at a higher level resulted in the dump at the end of the stack. 

There are two things to remember about the ABAP call stack:

• It's a call stack and not a complete history of calls. If the flow of execution returns from the last callee in the stack, that return from the callee is not shown in the stack.  If the short dump occurs in the caller, then you might wonder why the stack shows a different program as the end point of execution than the What happened section.
  
• If ABAP dumped because of an incompatible call to a function module or method (CALL_FUNCTION_CONFLICT_GEN_TYP, CALL_FUNCTION_CONFLICT_LENG, CALL_METHOD_CONFLICT_TYPE, ...), then the called function or method will not appear as the last level in the call stack.  The call itself failed, so the callee is not shown in the stack.

Where Did It Happen: The Hard Way

Usually, the Source Code Extract shows where your error occurred.  But if you are unlucky, you may have to determine this vital piece of information the hard way. As a not so tragic example, if a short dump occurs in a macro, then the source code pointer will be set to the macro call, not to the statement in the macro that caused the problem. 

An error in the kernel may leave no information in the Source Code Extract at all. 

In cases like these, how can you find out where the short dump occurred?

Let's start with the no-source-code-its-a-macro case.  The Source Code Extract does show where the misbehaving macro was called.  Since you can jump into the ABAP Editor and then forward-navigate into the macro with a couple of clicks, you can first see if a good look at the macro code might reveal the problem. 

If you still can't see where in the source code the problem occurred, then the ABAP Control Blocks (CONT) section may help you to localize the problem.  The CONT table shows the CCBs - Control-Control-Blocks - which represent the ABAP statements to be executed in the processing blocks of an ABAP program. The short dump contains an extract of the CONT table showing the CCBs that lead up to the dump and the next few statements that were to be processed.  Read the list of CCBs from the top down.

Low-level as it is, the CONT does not care whether statements are in a macro or not - and it shows the short dump pointer that you know from the Source Code Extract. Unfortunately, a double-click on the CCB at the dump pointer still takes you only to point in the source code at which the bad macro was called.  But the halfway intelligible CCB names may be enough to show you at which line of code in the macro the problem occurred. 

First of all, if the macro is not too long, then clicking on the CCBs to jump into the ABAP Editor shows you where the macro started.  Then, with a little jumping back and forth between the CONT table and the ABAP Editor, you can start to equate the CCBs and the statements in the faulty code. 

In our case, the SQLS and PAR1 CCBs turn out to reference an SQL SELECT well before the macro call. CCB 68, BRAF, represents the start of an IF control structure in which the macro is called. The COND and PAR1 CCBs depict the macro statement that actually failed:  CONCATENATE &1 ‘.sap.corp' into &1.

In the case I-have-only-a-kernel-dump (SYSTEM_CORE_DUMPED, ABAP_ASSERT, etc.), the Source Code Extract section will really be empty.  In this case, the dump section Active Calls in SAP Kernel provides clues as to the location of the error.  But since no customer or ABAP application developer should have to read a kernel stack, we mention this only for the record. If you have a short dump that originated in the kernel and it is not simply because somebody pulled the plug on the ABAP AS, then all you need to do is provide the short dump with the Active Calls in SAP Kernel section to SAP Support.  

Other situations with no where-it-happened location:   Should you not have any luck in finding out exactly where the program went down the tubes, then a useful tip is to try to reproduce the problem in transaction SAT, the ABAP Runtime Analysis. In SAT, you can trace the execution of an ABAP program at the level of ABAP processing blocks. Run your program to its dump (provided that this does not take too long - a non-aggregated SAT trace can get large quickly).  Then check the SAT trace.  It may help you find out pretty exactly where to look for the problem, even if the dump occurred in a macro.

Also, you can use ST05, the Performance Analysis, to switch on (in a controlled fashion - for your user, for example) a detailed trace of program activity. Be aware that the trace will also include the writing of the short dump.  The dump processing starts where you find activity on DB table SNAP, so search for the problem area before that point. 

See help.sap.com for help with using SAT and ST05.

The Third Major Question:  What's the Solution? 

Naturally, the discussion that you will find in the How to correct the error section of a short dump tends to be a bit generic.  Developers are constantly finding new and inventive ways to repeat old errors, like the MOVE_TO_LIT_NOTALLOWED_NODATA error that we have been examining.  It's therefore not possible for How to correct the error to describe exactly what you should do to fix a dumping program.

Even so, the combination of the discussion in How to correct the error and taking a good look at the faulty code often leads to success in correcting the problem.  In the case of the MOVE_TO_LIT_NOTALLOWED_WA dump that we have been examining, the dump astutely remarks that ‘The field to be overwritten is a parameter or a field symbol.' If you were not aware that the sort keys of a sorted table may not be overwritten in a field symbol, then the tip that a field symbol may be involved might help you get onto the right analytical track. 

In the end, however, understanding and correcting the cause of a short dump rests on your shoulders. You will have to extract as much information from the short dump as possible, and use this information to illuminate what went wrong in the code. 

Gathering More Information

A short dump addresses more or less directly the journalistic questions of what went wrong where and what to do. Should these questions be addressed ‘less' rather than ‘more' in a dump, then it is good to know that a dump also includes a lot of additional supporting information that can help you in your analysis.

System Variables

As an ABAP program executes, it is accompanied by an entire swarm of system variables, like Jupiter with its cloud of little moons. Some of these variables are well-known, like SY-SUBRC, the return code set by many ABAP instructions or SY-TABIX, the counter in LOOP AT and READ TABLE internal table instructions. 

When a short dump occurs, ABAP preserves the state of the system variables at the time of the crash.  You can see the contents of these variables in the Contents of system fields section.  Here are some of the system variables that are most likely to be useful:

• SY-SUBRC usually shows the last return code setting before the program crashed.  A non-zero SY-SUBRC from a method or function preceding an instruction that dumped may illuminate for you what went wrong.
  
• SY-TABIX. In a short dump raised from within a LOOP AT table or after a READ TABLE instruction, SY-TABIX tells you what record from the internal table was being processed when the program failed.
  
• SY-INDEX provides the same iteration-count information for DO and WHILE loops. 
  
• SY-LINNO (number of lines in an ABAP list) and SY-COLNO (number of columns in an ABAP list) show how much memory a large ABAP list consumes, if you are having memory problems with a large list.
  
• SY-MSGID and SY-MSGNO, if set, let you look up the last message issued by the failed program in transaction SE91.  SY-MSGV1 - 4 show any message variables that previously were set (not necessarily for use in the most recent message).
  
• SY-DATUM and SY-UZEIT may show a more accurate and earlier time stamp for the initial program abort than the date and time associated with the short dump itself. If you are sifting through the System Log or Developer Traces (see the Part I of this weblog), then the few seconds difference that you may see can be important in establishing to chronology of events in a failure.

Program Variables

For the Chosen variables section, the short dump infrastructure takes a quick run through the collapsing program context  grabbing any program  and infrastructure variables it finds that are currently in scope.  The situation is a bit like the belated shopper running through a grocery just at closing time - there's no guarantee that the shopper will bring home everything that he or she was supposed to buy.  Even though the dump infrastructure may not capture everything, much more often than not you will find the variables and values that you want to see. 

Since SAP_BASIS Release 6.20, the short dump infrastructure has captured a separate set of Chosen variables for each level in the Active Events/Calls ABAP call stack.

If you are analyzing a data-related problem, then a careful look at the Chosen variables may clarify the problem. In one recent example, an OSS message reported a short dump because ABAP could not convert the character value 229812 to an integer (dump ID CONVT_NO_NUMBER). Since this is one of ABAP's easiest tricks, the dump is at first glance pretty mystifying.  A quick look at the character field in Chosen variables showed, however, that the character field held not ‘229812' but rather ‘229812##믆䀾##蠤䋒##p###'. The fact that the field was either not correctly initialized or was filled with non-character data explains the conversion failure, at the very least.

Chosen variables shows the size (here, one record with a length of 3440 bytes) of an internal table, as well as useful information such as the type of organization of the table (here, a sorted table).  The table display can be useful in analyzing the popular dump of type TSV_TNEW_PAGE_ALLOC_FAILED (no more memory available for an internal table), since you can see how much memory has been allocated to hold the rows of  each internal table.  (The amount of storage allocated for the rows may not, however, be the amount of storage used by the rows of the table. If, for example, a table holds only data references to objects, then storage for references may not be all the memory actually consumed by the table and its contents.  The references are relatively short. The objects may occupy much larger amounts of memory.)  

In an upcoming release, the table display will contain at least the start of the contents of each of the first five records of each internal table that is captured.

Finally, object references that have not been initialized (a favorite cause of OBJECTS_OBJREF_NOT_ASSIGNED_NO, and others...) are easy to pick out in Chosen variables.  Just use Ctrl - F to search for ‘:initial}'.

Note that a random mouse click in the Chosen variables display switches the display from the relatively attractive formatted view to an unformatted view.  Don't be alarmed. Just click on F3 / Back to return to the formatted display.

An Ounce of Prevention... 

Is worth a pound of cure, as the old saying goes. 

Don't forget that ABAP offers logging and checkpoints that can be activated when needed (see help.sap.com).  With these, you can turn on switchable logging, breakpoints, and assertions to help you with diagnosis and trouble-shooting, should something go wrong in your program after it has reached your users.

And don't forget the suite of tools that the ABAP Workbench offers to help you find errors before your users do, starting with tools for static checking like the Code Inspector (Transaction SCI), continuing with the ABAP Unit Test facility, with which you can even go so far as to practice test-driver development.  The best ABAP short dump is the one that you never have to analyze.

- This weblog is based in part on Boris Gebhardt's Advanced ABAP Workshop: ABAP Analysis Tools. You can find more information on ABAP Test and Analysis Tools at help.sap.com and also in ABAP: Advanced Tools and Techniques, Volume 2, SAP Press 2009, ISBN 978-3-8362-1151-2.

Here’s a tip for those of you out there who are responsible for quality testing using ABAP Unit module tests.  You can automate ABAP Unit runs with the ABAP Code Inspector as of  Release NW04 (6.40).

Let me explain why this is a useful tip.  For most quality advocates, the first task is to get your developers to implement ABAP Unit tests.  

But once you have ABAP Unit tests in place, then a second, problematic task emerges:  Running the ABAP Unit tests regularly.  After all, you created the unit tests because you wanted to detect problems introduced into existing functions by changes in coding, and you wanted to be able to verify that new coding works as designed.

To achieve these desirable results, you need to run a perhaps quite large set of unit tests more or less regularly, when code arrives in your test system.  It is a bit tedious, however, to travel through the relevant classes, function groups, programs in the ABAP Object Navigator calling Test -> Unit Test off the context menu at each stop.   

Fortunately the Code Inspector of the ABAP Workbench provides a convenient way for you to automate executions – and even track results – of selected sets of ABAP Unit tests.  Here is how to do this: 

1. Start the Code Inspector (transaction SCI) in your testing system.  
   
2. Create an object set that specifies what ABAP Unit tests are to be run. 
   
   
3. Pick out the ABAP classes, programs, and function groups whose unit tests are to run under this object set. 
   
   Ideally, you can just specify the set of packages in which you are actively developing.  Leave Save Selections Only on to select objects according to object assignments fresh every time that you use the object set.
   
   
   
   When you are ready, save the object set and return to the SCI start screen.
   
4. Create a check variant.
   
   
    
5. Mark only the Dynamic Tests option on the Check Variant screen.  Then save your check variant and return to the SCI start screen.
   
   
   
6. Now you can create an inspection that uses the object set and check variant that you just created.
   
   
   
   
    
7. The Execute button with … opens a window in which you decide how to run the inspection.  As the screen shot shows, set the inspection to run as a background job. Whenever the job runs, all of the ABAP Unit tests in the object set will be run. The Code Inspector saves the results of each run.
   
   
   
   All of the repetition features of ABAP background processing are available to you – but if you import code on a regular schedule, then you probably need only schedule the job periodically.
   
   Here, the ABAP Units inspection is scheduled to run immediately as a background job and will be repeated weekly.
   
   
    
8. A finished inspection is marked with a green icon, as you can see here. Clicking on Possible Entries (F4) in the Inspection field shows you the status of the current and past inspections.  Click on an inspection to open it.
   
   
   
   Then click on the Results button to see any messages issued by the ABAP Unit tests.