Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Issue in ABAP Unit Test

Former Member
0 Likes
1,760

Hi,

I am having an issue in Unit Testing of Function Module. The issue is that Interface parameter of FM is not accessed in subroutine as the parameter goes like a field symbol. I get a dump while try to access the Interface parameter.

Can anyone please help me out on this.

Hi,

I am having an issue in Unit Testing of Function Module. The issue is that Interface parameter of FM is not accessed in subroutine as the parameter goes like a field symbol. I get a dump while try to access the Interface parameter.

Can anyone please help me out on this.

8 REPLIES 8
Read only

former_member187748
Active Contributor
0 Likes
1,639

Hi Bhavya,

can you please paste your dump screenshot.

Read only

Sayan_C
Explorer
0 Likes
1,639

Hi,

I guess you parameter as a field symbol is wrong data type. You field symbol have to assign the same as FM parameters.

Hope it help,

Sayan.

Read only

Former Member
0 Likes
1,639

hi Bhavya,

Try blow code:

Field symbols <gt_table>.type any table.

Data: lr_data  type ref to data.

    get reference of t_outtab(the name of parameter) into lr_data.

    assign lr_data->* to <gt_table>.

regards,

Archer

Read only

0 Likes
1,639

Hi,

My concern is specifically in case of Unit testing.

Let me know whether I should paste this code in Unit class method or in subroutine.

Read only

sreeramkumar_madisetty
Active Contributor
0 Likes
1,639

Hi

Can you paste your code.

Field symbols <Lt_table> type any.

Data: ls_data  type ref to data.

    get reference of t_outtab(the name of parameter) into ls_data.

    assign ls_data->* to <Lt_table>.

Regards,

Sreeram

Read only

0 Likes
1,639

* Following is my Unit Test Method

METHOD get_user_formats.

     DATA lv_format   TYPE char35.

     PERFORM get_user_formats USING '2'.

     READ TABLE user_format INTO lv_format INDEX 1.

     " Expected Result

     cl_aunit_assert=>assert_equals( act = lv_format

                                     exp = 'DATE = MM/DD/YYYY').

   ENDMETHOD.     



FORM get_user_formats USING datfm TYPE datfm.

   DATA: lv_format   TYPE char35.

   SELECT SINGLE ddtext FROM dd07t INTO lv_format

          WHERE domname = 'XUDATFM' AND

               ddlanguage sy-langu AND domvalue_l = datfm.

   CONCATENATE 'DATE = ' lv_format INTO lv_format SEPARATED BY space.

   APPEND lv_format TO user_format.

   CLEAR lv_format.

* Comment: user_format is a table in TABLES parameter of FM. It is having single field of type CHAR35

ENDFORM.                    " get_user_formats


Please note that I get dump ONLY at the time UNIT TESTING. Otherwise the program is running fine.

Read only

Former Member
0 Likes
1,639

I suppose the only way to handle this situation is by passing the table as USING (or CHANGING or TABLES) parameter of subroutine.

Any other suggestions will be helpful.

Read only

0 Likes
1,639

Hello Garg,

as far I got the code snippets the form routine accesses a global variable which is defined as parameter of a function module.

In case the function module is not used and the parameter is not fully typeD this may cause issues as you have reported. Possibly a fully typed of the function module improves the situatuion, on the other hand stronger typing is an incompatible change of the function.

A less invasive alternative is not to use global references in the implementation but to use well defined signatures. On related track I would consider to refactor the form routine to a static method with explicit signature. Please note that methods of local classes have a superior signature typ system compared to forms. As effect methods tend to be faster than forms and the better typed signature avoid flaws from the very beginnging. Another benefit is that the compiler is more strict for method implementations. This strictness is a true benefit as following the more strict rules your code gets faster and more reliable.

Best Regards

  Klaus